Кто как работает с битами? Опции

[amost]

avr-gcc

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

может наверняка есть какой-то более удобный метод. макрос, определяющий имя байта с флагами по имени бита, что-ли.

Сообщение отредактировал amost - Jun 19 2010, 09:19

[zltigo]

avr-gcc
раньше....

Как Вам уже сказал Dog Pawlowa - так и продолжайте, только добавьте имя регистра. Типа:

CODE

#define SIS5_LIG(x)    (((x)&0x3)<<6)
#define SIS5_LIM        BIT5
#define SIS5_MCG(x)    (((x)&0x3)<<3)
#define SIS5_MCM        BIT2
#define SIS5_HIM        BIT1
#define SIS5_IIR        BIT0

......
    si_write( SIS5, SIS5_LIG(LIG_20DB)|SIS5_MCG(0)|SIS5_MCM|SIS5_HIM);    // Line Gain +20dB
    si_write( SIS6, SIS6_RXG(RXG_0DB)|SIS6_LO_ON);             // RX 0dB Line Out Active

......
void si_write( int reg, bint data )
{
    if( ( reg >= SIS1 )&&( reg <= SIS9 ) )
    {
        if( !xIsTimeout( si3000_time ) )
            vSmartDelay( 1 );
        fpga_cmd( FCMD_SI3000|FCMD_WR, (reg<<8)|(BYTE)data );
        si_reg[reg] = (BYTE)data;
        si3000_time = xGetTimeout( 1 );
    }
    else
        xprintf( "SI:Invalid REG:%2X\r", reg );
}

Проверено на собственной шкуре многими годами поисков и применения разных "извратов".

[demiurg_spb]

На платформах, не имеющих атомарного битового доступа к ОЗУ,
использовать битовые переменные нерационально если:
1. они volatile
2. их достаточно мало (не стоит жмотиться и выиграть аж целых 20-50 байт ОЗУ)
3. они не расположены в sfr области (см п.1).

Я в 99% случаев под флаги использую целую ячейку памяти (байт или даже крупнее) и в ус не дую...

Оптимизация ресурсов ОЗУ не должна быть самоцелью...

[zltigo]

Я в 99% случаев под флаги использую целую ячейку памяти (байт или даже крупнее) и в ус не дую...

Ну и зря, в тех-же 99 случаях флаги не используются отдельно, а "кучкуются" и лазить за каждым флагом в память, вместо работы с этими флагами в единожды загруженном одном регистре это уже не только растраты памяти, но и производительности. Естественно, случаи бывают разными. И железо бывает разным.

[demiurg_spb]

Ну и зря, в тех-же 99 случаях флаги не используются отдельно, а "кучкуются" и лазить за каждым флагом в память, вместо работы с этими флагами в единожды загруженном одном регистре это уже не только растраты памяти, но и производительности. Естественно, случаи бывают разными. И железо бывает разным.

Конечно, они могут и кучковаться, а могут и нет. Это меня даже не сильно заботит.
Меня во всей этой ситуации всегда напрягала необходимость использования критической секции.
И даже если они (флаги) обрабатываются пачками по 3-5 штук ещё не известно что будет оптимальнее прочитать 3-5 байт из ОЗУ или вкрячить критичекую секцию, добавив при этом лишнюю латентность (пусть даже и копеечную).
Мне всегда ближе наиболее простой вариант. И код не засорён лишними временными промежуточными переменными.

[zltigo]

И даже если они (флаги) обрабатываются пачками по 3-5 штук ещё не известно что будет оптимальнее прочитать 3-5 байт из ОЗУ или вкрячить критичекую секцию, добавив при этом лишнюю латентность (пусть даже и копеечную).

А зачем приплетать всуе слова "критическая секция". Эта сущность в общем случае совершенно отдельная. Если Вы не задумываясь щедрой рукой разбрасываете volatile да critical, и знаете только одну систему команд, то это не значит, что все должны следовать Вашему "примеру" и разбрасываться ресурсами .

[demiurg_spb]

А зачем приплетать всуе слова "критическая секция". Эта сущность в общем случае совершенно отдельная. Если Вы не задумываясь щедрой рукой разбрасываете volatile да critical, и знаете только одну систему команд, то это не значит, что все должны следовать Вашему "примеру" и разбрасываться ресурсами .

Пусть хоть один флаг волатилен, он и всех собратьев (из одного байта) сделает таковыми.
Оно надо? Да я даю реально упрощающий жизнь пример. Когда не надо помнить ни про волатильность ни про то что особо умный и жадный программист разделил волатильные флаги от неволатильных, а потом забыл об этом ненароком он сам или наследники его таланта.
Зачем закладывать грабли когда можно и нужно без них обходиться.
Просто. Надёжно. Без геморроя. Быстро и не требует лишней писанины (я об описании через дефайны мути в виде масок, что вообще применимо лишь для описании периферии). Хочется воскликнуть: Ау! мы пишем на Си а не на я языке препроцессора в конце то концов...

А Вы всё о какой-то мифической экономии ресурсов печётесь.
Не здесь блох ловить стоит 20 байт озу и 5-20 тиков тактовой.
Не мне Вам объяснять где. Вы сами прекрасно знаете про вынесение из цикла всякой чуши, про их разворачивание, про правильный (нативный) выбор типов данных и про уместное использование volatile да и вообще о культуре программирования.

А то право смешно даже становится как Вы упираетесь и особо смешно, что даже немного грустно,
от того что Ваша привычка домысливать и додумывать об умениях и интеллекте Ваших собеседников крепчает с годами...
Радует что пока до обсуждения ближайших родственников оппонентов дело не доходит...

Совершенно зря, у Cortex есть фича упрощающая работу с битами называется она "Bit Banding"
Все ваши флаги можно было упаковать в одно слово, а там работай хоть через маски хоть через Bit Banding.

Это отлично! Через пару месяцев ему потребуется портировать проект под процессор XXX с адресным пространством чуть меньшим чем 4Gb без Bit Banding... "О сколько нам открытий чудных готовит просвещения дух!" - это я не к тому чтобы не использовать новую полезную фичу, а к тому что и старая даёт сопоставимый результат.

Ну нет в Си полноценного типа данных меньшего чем uint_fast8_t!