[sonycman 0]

typedef __UINT_FAST8_T_TYPE__ uint_fast8_t;

А у меня в Кейле:

typedef unsigned           int uint_fast8_t;

[zltigo 1]

Вообще? Или там, где нет нативного типа?

Вообще, ибо в приведенной трактовке он никаких проблем не решает и ведет себя, как и char/int/ только еще и имеет не предсакзуемый размер.

[_Pasha 0]

или встроенный.

Интересно. Из какого компилера  __UINT_FAST8_T_TYPE__ ?

 

Согласитесь, лучше атрибутами бы "встроенность" обеспечивали.

[zltigo 1]

А у меня в Кейле:

Понятно. В IAR встроенный и ведет себя (по крайней мере плотно экспериментировал во времена массового портирования с 8/16bit с least8 ) за счеет этого несколько интелектуальнее.

[_Pasha 0]

В IAR встроенный и ведет себя .... несколько интелектуальнее.

Может, Вы приведете пример, где свойства _least и _fast расходятся? Ну нигде не найду возможности осязать разницы! :smile3046:

[zltigo 1]

Может, Вы приведете пример, где свойства _least и _fast расходятся? Ну нигде не найду возможности осязать разницы! :smile3046:

На ARM платформе fast всегда был( видел) только 32bit, а least в некоторых контекстах становился восьмибитовиком. Ну а для полатформ типа x86 c их кусочками регистров и гибкой адресации к памяти оставляют много больший простор, для компилятора.

Те-же 8bit в памяти выровняные на границу слова ничуть не медленнее 32bit. А если нет, то....

[_Pasha 0]

для полатформ типа x86 c их кусочками регистров и гибкой адресации к памяти

Спасибо! Как-то подзабыл об этом...

Те-же 8bit в памяти выровняные на границу слова ничуть не медленнее 32bit.

Т.е. в идеале на Load/Store архитектурах тот же uint_least8_t в памяти займет 1(2) байт, а в регистре - ширину регистра? И дальше ничем от _fast отличаться не будет?

[dxp 53]

Как по мне - так "вообще". Достаточно обычного С-шного соглашения о том, что ложь - ==0, истина - !=0.

Вообще, ибо в приведенной трактовке он никаких проблем не решает и ведет себя, как и char/int/ только еще и имеет не предсакзуемый размер.

А вот неглупые дяди приводят такие аргументы (цитирую):

 

• тип Boolean существует вне зависимости от того, есть он в стандарте С++ или нет;
• наличие множества конфликтующих друг с другом определений делает неудобным и небезопасным любой тип Boolean;
• многие пользователи хотят иметь возможность перегружать функции на базе типа Boolean.

 

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

 

Что касается размера, то размер его вполне предскзуемый и зависит от реализации. Ровно как и в случае с char, int, enum, double.

[zltigo 1]

И я полностью согласен со всем тремя аргументами.

Странно :( лично мне достаточно второго аргумента, дабы его не пользовать.

Сам давно и регулярно юзаю плюсовый bool, что нахожу наглядным, логичным и удобным, и никогда не испытывал с ним проблем

Я в С99 в моих ситуациях тоже не жаловался, но честно говоря, представлял себе, это много более безопасным, нежели приведенная реализация bool в GCC.

Что касается размера, то размер его вполне предскзуемый и зависит от реализации. Ровно как и в случае с char, int, enum, double.

Так "предсказуемый" или "завистит от реализации"? Со всеми вышеперечисленными, включая enuм действительно ясно (в рамках зависящих от платформы), а вот что такое боол и размер достаточный для его хранения? Огласите, сколько это в битах, как размещается в регистрах, как в памяти, как пакуется в структуры, union-ы..... Лично я могу только "предсказать" одну логичную с точки зрения универсальности реализации - int.

 

Т.е. в идеале на Load/Store архитектурах тот же uint_least8_t в памяти займет 1(2) байт, а в регистре - ширину регистра? И дальше ничем от _fast отличаться не будет?

Ну что-то где-то так. Только я в конце концов стал делать это через свои типы, поскольку мне это нужно было прежде всего для портирования, а замена какого-нибудь char на fast8 в трактовке Keil может легко выйти боком.

[s.qwertyuiop 0]

1) Как портировать софтину с АВР-8бит на АРМ, если у исходной подавляющее большинство локальных переменных char, а если это перенести на 32-битовые регистры - получим оверхед по выделению байта ? Говорено-переговорено на эту тему.

Я не большой знаток АРМа, но разве он не может оперировать байтами? И если нет, то как с ним вообще работать? И тогда чем он лучше сигнальных процессоров типа ADSP?

[aaarrr 69]

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

 

А уж чем ADSP не угодил - ума не приложу.

[Xenia 38]

Грустно, что обсуждение перешло обсуждение на размерности булевской переменной. По всей видимости, это произошло из-за того, что участники дискуссии путают "битность" процессора и шириной шины данных. Между тем, как это вещи в общем случае разные.

Разрядность регистров процессора может превосходить ширину шины данных (т.е. сетку физической адресации памяти), но наоборот быть не может. В своё время процессор i80386SX уже имел 32-разрядные регистры, когда как работал с 16-разрядной шиной памяти. Такая ситуация означает лишь необходимость в наличии инструкций по чтению/записи старшей и младшей части регистра и их комбинацию, обеспечивающую двухступенчатый обмен между целым регистром и двумя последовательными ячейками памяти.

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

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

Возвращаясь к микропроцессорам замечаем, что разрядность шины данных у них обычно мала. Т.е. данные передаются во внешнюю память силами одного, максимум двух портов. Например, у AVR32 шина данных памяти 16 бит (шину адреса я не посчитала). Это означает, 3что 32-битность на память не распространяется, поскольку ФИЗИЧЕСКИ память обменивается с процессором сразу 2-мя байтами. Стало быть и булевская переменная, если уж она так сильно вам нужна, будет в данном случае иметь 16-битную размерность.

Гораздо более существенным вопросом, чем размерность булевской переменной, является вопрос о размерности АДРЕСА памяти, что в первую очередь определяется максимальным объемом рабочей памяти. У AVR32 этот адрес занимает 24 бита. Именно отсюда и возникает преимущества 32-битности, что адрес целиком помещается в регистр. Тут уже не надо маяться, работая с адресом, как регистровой парой (операция по ее инкрементированию более сложна).

Ну а главное все-таки арифметика! Все мы знаем, что размерность произведения вдвое больше размерности данных. Вот тут-то длинные регистры очень кстати. И, наконец, преимущества длинных регистров поймут все те, кто хотя бы краешком глаза заглядывал на то, как реализуется в библиотеках эмуляция работы с плавающей точкой.

Изменено 17 июня, 2009 пользователем Xenia

[AHTOXA 15]

Не понял...

(if somevar != false) я ещё понимаю... а это как правильно обработать?

 

Ну как раз так и обрабатывается, сравнение (somevar == true) приводится к (somevar != false) :)

 

Ну, вы же помните разницу между & и && (| и ||, ~ и !).

 

Помню:) Однако я помню также, что инверсия бита на i51 получалась быстрее, если написать bit = ~bit. Но даже это не самое главное. Самое главное, что сам компилятор при обработке логических выражений не пользуется bool! Вот поэтому bool и продолжает оставаться слегка "сбоку" от языка.

 

Имхо, вся сложность C/C++ как языков и содержится в подобных нюансах, коих весьма немало. "Дьявол прячется в мелочах" (с) :)

 

Согласен :)

[Dx! 0]

У меня есть и такое

    if(PINB&0b00000010) //обработка джампера

(if somevar != false) я ещё понимаю... а это как правильно обработать?

волне можно использовать и if(somevar) - краткая запись. выполнится если этот самвар != 0 или if(!somevar) что одно и тоже с if(somevar == 0)

Как выше уже говорили - всё что == 0 - false а всё, что !=0 - true. Помнить это, да не путать логические и побитовые действия и в bool не будет надобности.

[zltigo 1]

Помнить это, да не путать логические и побитовые действия и в bool не будет надобности.

Дык, весь прикол в том, что если путать, то bool просто НИЧЕМ не помогает. Сюрприз!