Двигать можно - никто не запрещает. Результат будет такой же как с масками.

долго читал пэйджер, тьху мессагу. что то с точностью да на оборот Вы написали явно.
наоборот, единицы двигаются при создании группы бит = масок. когда у нас один бит - то собственно достаточно явно указать бит. правда не все регистры корректно могут воспринимать это (sbi, cbi).
и вроде как до вашей мессаги sbi & cbi команды вообще не рассматривались. т.е. речь шла конкретно о сдвиге и всё что вокруг него крутиться.

тут наверное ближе слово не архитектура а компилятор. т.к. на выходе (в бинарнике) будет одна сущность = байт, слово, двойное слово и т.д.. а как вы его получили или слепили(можно например умножать в целых числах, или логически объеденять в различных системах счисления) - для железа вовсе фиолетово.

Сообщение отредактировал kolobok0 - Jul 12 2012, 12:52

В том-то и дело, что из номеров битов можно состряпать маску (сдвигая ту самую едлиницу), тогда как обратное преобразование арифметическими средствами невозможно. Поэтому, если в хидерах/инклюдах имена битов опредены, как маски, то использовать их в качестве аргументов sbi/cbi будет нельзя. А вот определение их, как номер бита, позволяет делать и то и другое, с теми лишь накладными расходами, что приходится двигать единицу, когда нужна маска. И несмотря на то, что двигается эта единица не в процессе исполнения, а в процесе компиляции, битовые маски, образуемые большим набором битов, выглядят в таком исполнении чудовищно. А не было бы в инструкциях команд sbi/cbi, но не было бы и проблемы, т.к. ничто не мешало бы перейти на маски.

AVRASM & AVRASM2, установить в "1" бит 5 в регистре R16 и в PORTA.

Ух ты! Не думала, что ассемблер в времени компиляции способен вычислять логарифы. Отпад!

Это только называется так круто, а на деле двоичный, де ещё и целочисленный логарифм это и есть номер самого старшего бита в слове.

PS. У кортексов, кстати, есть команда CLZ, вычисляющая количество ведущих нулей в слове.

Про двоичный логарифм и так ясно, а удивилась тому, что функции во время компиляции способен выполнять. Скажем, MS Visual C/C++ функций выполнять не станет - только арифметико-логические выражения. А когда siziof() в хидере не захотел компилить, то я и вовсе разозлилась.

А почему Вы не напомнили, что макрос (1<<(x)) давно обозвали BIT(x). Читать совсем удобно.

Возможно потому, что я понятия не имею, кто и где его так обозвал. Создатели avr-libc с вами не согласны - они обозвали такой макрос _BV(x). В то время как конструкция (1 <<(x)) совершенно однозначно понимается любым компилятором C, C++, "языков, похожих на C", многими ассемблерами и любым программистом, знающим любой из этих языков.

А еще обратите внимание на приведенную мной запись Здесь совершенно четко видно - какой бит в нуле, а какой - в единице. И чтобы изменить значение бита, достаточно заменить ноль на единицу или наоборот. В случае же BIT(x) или битовых масок придется делать либо (1*BIT(x))|(0*BIT(y)), либо комментировать части выражения. Оба варианта совсем не добавляют читабельности. Еще для сброса бита можно удалять части выражения, но это тоже неудобно, ибо когда понадобится эту часть выражения снова вернуть - в большинстве случаев придется лезть в даташит/заголовочный файл, чтобы уточнить название добавляемого бита.

Может быть отказался компилить, потому что на момент обработки этого sizeof размер был неизвестен (incomplete type)? Зачем расходовать нервные клетки? Просто поставьте себя на место компилятора. И на его месте, вероятно, вы бы сказали "Не виноватая я!!!..."

Да, сорри, запамятовал, _BV


Для неустановки в 1 достаточно не писать _BV(BIT). Это будет даже нагляднее.

Танунет. Это плохая практика, совсем. В смысле портабельности, а чего мы здесь сеголня собрались? Ассемблер только повод...


Всегда говорил, что это идеологиццкая полумера:
Раз есть _BV, должен быть и _nBV


Сообщение отредактировал _Pasha - Jul 13 2012, 00:32

_BV(3) | _BV(5) = 0x28
_BV(3) | _nBV(5) = 0xFF

вместо ожидаемых:
1<<3 | 1<<5 = 0x28
1<<3 | 0<<5 = 0x08

Скорее, было
Поскольку sizeof — оператор языка, в препроцессоре он не должен работать.

Э... нет. Вводная была "отказался компилить", а не "компилил неправильно"

Ага! Именно так и было. Задумка была такая, чтобы после определения структуры проверить во сколько байт она компилится, чтобы вовремя забить тревогу, если был установлен неправильный align с выравниванием размера полей. Borland C/C++ (и его потомки) нормально это компилируют, а MS Visual C/C++ уперся рогом.