Ви не увійшли.
дофига не дофига, но я, например, окромя gcc пользовался еще codevision и iar. и как то кумарило, что попадались такие макросы, что свойственны конкретному компилятору.
![]()
в сторонніх лібах може бути що завгодно.
Неактивний
в сторонніх лібах може бути що завгодно.
Не в либах дело. Например, для размещения данных во флеш, у gcc используется PROGMEM, у IAR-а __flash, у CVAVR просто flash. Свои директивы. Это же касается и асм вставок, надо писать именно так, как хочет конкретный компилятор, и пофиг что у другого по другому, они никогда не будут совместимы в этом плане.
Активний
Kino пише:Посмотрел. Раскладывается в тот же #define bit(b) (1UL << (b)).
1UL. В avr-libc просто 1.
та дурня. UL это просто unsigned long, т.е. захватывает 4 байта. Если я напишу 1ULL это будет восемь байт, то шо, я еще круче?
Активний
Не в либах дело. Например, для размещения данных во флеш, у gcc используется PROGMEM
В gcc є підтримка named address spaces (ISO/IEC DTR 18037), так що в C __flash працює (для читання генерується lpm). В arduino, яке базується на C++, такого не буде.
Это же касается и асм вставок, надо писать именно так, как хочет конкретный компилятор, и пофиг что у другого по другому, они никогда не будут совместимы в этом плане.
Бо inline assembler не є частиною стандарту, це розширення конкретного компілятора.
Активний
та дурня. UL это просто unsigned long, т.е. захватывает 4 байта. Если я напишу 1ULL это будет восемь байт, то шо, я еще круче?
Суть не в long, а в unsigned. Поведінка (1 << 15) при 16-бітному int не визначена стандартом. Те ж саме з (1 << 31) на платформах з 32-бітним int.
Активний
В gcc є підтримка named address spaces (ISO/IEC DTR 18037), так що в C __flash працює (для читання генерується lpm). В arduino, яке базується на C++, такого не буде.
Та блин, эти стандарты уже так разрослись и отличаются, что уже не уследишь. )) Например, под тот же esp32, если написал достаточно объемный проект на родном фреймворке esp-idf, то адаптировать, чтобы он собрался на фрейме arduino тот еще гемор, проще переписать заново.
Активний
Поведінка (1 << 15) при 16-бітному int не визначена стандартом.
За стандарт не скажу, честно не знаю. Но помню книжка писала, что если не указано явно unsigned, то по умолчанию переменная всегда signed.
Активний
Та блин, эти стандарты уже так разрослись и отличаются, что уже не уследишь. ))
Стандартів для мов програмування не так уже й багато. Але так, вендори заліза клепають свої фреймворки з велосипедами на костилях. Тут нічого не поробиш, се ля ві.
Активний
За стандарт не скажу, честно не знаю. Но помню книжка писала, что если не указано явно unsigned, то по умолчанию переменная всегда signed.
Саме так. А при зсуві signed:
The result of E1 << E2 is E1 left-shifted E2 bit positions; ... If E1 has a signed type and nonnegative value, and E1 × 2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.
Остання редакція dimich (Сьогодні 21:11:31)
Активний
Саме так. А при зсуві signed:
Хм. Надо почитать, никогда не задавался этим вопросом. Всегда казалось, что сдвиг это команда LSL (LSR) с установкой флага переноса и этому флагу ваще побоку знаковое число или нет, просто ячейка, что выпадает переносится во флаг и по нему уже идет анализ установлен был бит или нет. Понятно что по этому же флагу (carry) определяется знак, но в случае "обычного" сдвига как бы зачем?
Остання редакція Kino (Сьогодні 21:30:43)
Активний
Всегда казалось, что сдвиг это команда LSL (LSR) с установкой флага переноса
Це вже деталі імплементації для конкретної архітектури. Я маю на увазі з точки зору стандарту мови програмування в загальному. Він нічого "не знає" про біти, флаги та інструкції.
Остання редакція dimich (Сьогодні 21:37:15)
Активний
Я маю на увазі з точки зору стандарту мови програмування в загальному. Він нічого "не знає" про біти, флаги та інструкції.
Ну в целом логично, если число знаковое, то он не понимает как можно сдвинуть знак без самого, собственно, числа.
Активний