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

[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!

[Herz]

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

Простите, что влезаю в интеллигентный разговор, но я в С не видел такого типа. Наверное, речь не об ANSI C?

[demiurg_spb]

stdint.h часть С99

http://en.wikipedia.org/wiki/C_library

[Herz]

stdint.h часть С99

http://en.wikipedia.org/wiki/C_library

[attachment=45192:Clipboard02.jpg] ?

[rezident]

?

Не читайте советских газет перед обедом не ориентируйтесь на Википедию как на истину в последней инстанции. Справляйтесь у оригинала стандарта ISO/IEC 9899:1999 (E).

7.18.1.3 Fastest minimum-width integer types
1Each of the following types designates an integer type that is usually fastest
216)
to operate
with among all integer types that have atleast the specified width.
2The typedef name int_fastN_t designates the fastest signed integer type with a width
of at least N.The typedef name uint_fastN_t designates the fastest unsigned integer
type with a width of at least N.
3The following types are required:
int_fast8_t
int_fast16_t
int_fast32_t
int_fast64_t
uint_fast8_t
uint_fast16_t
uint_fast32_t
uint_fast64_t
All other types of this form are optional.

[zltigo]

стандарта ISO/IEC 9899:1999 (E)

Ну свежие драфты не забывать ISO/IEC 9899:201x Крайний August 11, 2008. В них тоже уже изменений накопилось.