Битовые поля vs битовые маски, Что лучше для эмбеддера? Опции

[sigmaN]

Доброго времени суток.

Битовые поля - кто за, кто против??

Да, знаю, что задаю в принципе извечный вопрос, однако ответа толкового в Интернете не нашел..
Кто-то говорит, что они помогают экономить память, кто-то - что эффективнее or'ить xor'ить и and'ить используя битовые маски и операции сдвига. Типа у bitfield overhead некий появляется, как плата за удобочитаемость....

Лично я склоняюсь к битовым маскам. Так мне привычнее и кажется, что для регистра лучше задефайнить что-то типа
#define BIT0 0x001
. . .
#define BIT15 0x8000
#define REGISTERx (*(volatile unsigned long *)(0x00D00))

а потом ставить биты REGISTERx|=BIT0+BIT3+BIT7;
или REGISTERx|=1<<7; //Ставим бит 7

Во всех примерах Техаса регистры закручены в битовые поля, они ссылаются друг на друга, адреса в линкер .cmd файле и т.д. и т.п.
Это же ужас! И никакой удобочитаемости это особо не добавляет. Часа два ушло у меня, чтобы толком разобраться что куда и откуда линкуется.
Неужели это всё может превзойти старые добрые методы?

Я всё-таки переделал на свой лад.
Потом задумался, а может зря... Может особо ничего и не выиграл ))
Оперативка очень важна. Иду впритык, каждый байт на счету.

[sigmaN]

Отлично! Значит правильно я сделал - сейчас работаю именно с периферией.

Также часто необходимо просто присвоить всему регистру начальное значение, и это тоже невозможно при использовании битовых полей - приходится битовое поле заворачивать в union и в итоге писанины получается намного больше.

Вот вот, я когда на это всё посмотрел в техасовских примерах, сразу понял, что это не самое красивое решение.

Например, у того же техасовского TMS320C6x есть такая замечательная инструкция EXT

Гляну как у нас на 28мых с этим. Накрайняк макрос забить с ассемблерной вставкой и можно даже вручную кое-что оптимизировать.

Всем спасибо за ответы

[DMax]

Гляну как у нас на 28мых с этим. Накрайняк макрос забить с ассемблерной вставкой и можно даже вручную кое-что оптимизировать.

Ты того - с ассемблерными вставками поосторожней! Любая ассемблерная вставки приводит к тому, что компилятору приходится сбрасывать оптимизатор после того, как он наткнулся на это вставку. Гораздо лучше для этих целей использовать intrinsic'и, если они есть.

[sigmaN]

Ты того - с ассемблерными вставками поосторожней!

Покорнейше прошу разъяснить, как-же мне без асма сделать к примеру запрет прерываний, если нужно чтобы компилер встявил именно setc INTM и не что иное?
Ничего кроме
#define DINT asm("setc INTM")
мне в голову не приходит.
И как-же мне заюзать "замечательную инструкцию EXT", о которой шла речь, без асма?
Может, конечно, я не понял того, что ты предлагаешь....

И если говорить об insintric, то на сколько я понимаю, inline круче!
В случае intrinsic компилятор имеет право решать сам что делать(вызов функции или вставку кода в место вызова).

[zltigo]

как-же мне без асма сделать к примеру запрет прерываний, если нужно чтобы компилер встявил именно setc INTM и не что иное?

А что за компилятор для TMS320 не имеет в составе intrinsics чего-либо глобально запрещающего прерывания или генерящий "что-то иное"?

мне в голову не приходит.

Иногда нужно не только на свою голову полагаться, но и обращаться к документации.

Может, конечно, я не понял того, что ты предлагаешь....

Предлагается не пользоваться бездумно ASM вставками, там, где требуется качество кода, а не живописные заплатки демонстрирующие знание ASM и незнание инструментария. Если нужен ASM (для DSP это весьма частое явление - спору нет), то и писать этот кусочек нужно на ASM.

И если говорить об insintric, то на сколько я понимаю, inline круче!

Вообще-то "это", полагаю называется intrinsics, посему наверное Вам надо сначала разобраться, что есть одно и что есть другое.

Компиляторы бывают разные. Использование инлайн-асма в GCC безопасно..

Безопасность(работоспособность результата), это только одна из сторон использования ASM вставок. Вторая сторона это способность компилятора нормально оптимизировать такой, ломающийего "домашние заготовки" код.

[Сергей Борщ]

Вторая сторона это способность компилятора нормально оптимизировать такой, ломающийего "домашние заготовки" код.

Именно это я и имел ввиду. В GCC есть возможность указать компилятору, какие регистры (или память) портит асм-вставка, поэтому компилятор имеет возможность сохранить их или использовать в остальном коде оставшиеся свободными регистры. Также есть возможность не указывать регистр явно, а просто указать "регистр из такой-то группы" и компилятор сам подставит свободный на данном участке кода регистр. Таким образом "криминального" влияния на кодогенерацию нет.

[DMax]

Именно это я и имел ввиду. В GCC есть возможность указать компилятору, какие регистры (или память) портит асм-вставка, поэтому компилятор имеет возможность сохранить их или использовать в остальном коде оставшиеся свободными регистры. Также есть возможность не указывать регистр явно, а просто указать "регистр из такой-то группы" и компилятор сам подставит свободный на данном участке кода регистр. Таким образом "криминального" влияния на кодогенерацию нет.

В целом да, но в общем не всегда. Если ассемблерная вставка лезит в память, то тут уже компилятору приходится записывать все значения переменных из регистров в память до вставки, и после вставки их обратно считывать. Иногда такая особенность компилятора даже полезна, когда речь идет о написании приложений и ядер ОС, исполняющихся на нескольких процессорах. Тогда разработчики вставляют пустую ассемблерную вставку, где говорят компилятору, что она лезит в память. Такая штука называется memory barrier.

Где тут можно найти то, о чем я говорил?

...

И всё-же как быть?
В моем коде используются следующие ассемблерные вставочки-макросы
#define EINT asm(" clrc INTM")
#define DINT asm(" setc INTM")
#define ERTM asm(" clrc DBGM")
#define DRTM asm(" setc DBGM")
#define EALLOW asm(" EALLOW")
#define EDIS asm(" EDIS")
#define ESTOP0 asm(" ESTOP0")
#define IDLE asm(" IDLE")

Ответа в документации я не нахожу пока.... Может быть я не там смотрю ))
И я думаю такие безобидные спец. инструкции(не использующие ни регистры, ни память) особо не повлияют на ход событий при оптимизации...
Или тут опять есть свои подводные камни?
Тема для меня в принципе новая, поэтому может быть и всплывают такие вопросы

Компилятор не смотрит на то, что делают твой ассемблерные вставки. Он компилирует C, а не ассемблер. Представь себе, что ты компилятор. Ты компилируешь какой-то код, где решил что-то прооптимизировать, зачитав переменные в регистры. Затем ты натыкаешь на вставку. Ты не знаешь, что она делает. Возможно она портит твои регистры, возможно нет. Возможно она меняет значения переменных в памяти, которые ты загрузил в регистры, а возможно нет. В первом случае программист будет надеятся, что ты подхватишь из памяти новые значения, после того как отработает вставка. Вопрос к тебе как к компилятору: как при наличи такого черного ящика, сгенерировать такой код, который будет работать так, как это написал программист? Ответ один. Разрушить все свои предположения, а именно:
1) Не считать, что регистры, в которых закэшированны переменные, сохранили свое значение после вставки.
2) Не считать, что переменные, которые закэшированны в регистры, не изменились вставкой.
3) В зависимости от архитектуры могут поменятся различные флаги различных регистров состояний и т.п.

Таким образом, вставка бьет оптимизатору ниже пояса. И использовать их нужно как можно реже. Но бывают конечно моменты, когда без них не обойтись.

Все нужно делать с умом.