[_Pasha 0]

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

С чего Вы взяли? Просто пример _Bool наглядно показывает несуразности в представлении данных

Не процессор виноват в том, что один бит из памяти он достать не может...

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

1. Выделение битового пула 

2. Оптимизация размещения - исходя из анализа выражений.

Причем это же касается и операций с текстовыми символами

От этого ваще никуда не деться :) Char не пошлешь.

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

Лично мне более нравятся преимущества Barrel Shifter вместо циклов сдвига при нормализации/выравнивании :)

Теперь понятно. :) Как это компилятор внутри разруливает, его личное дело.

Почему же личное? Результат операции сравнения имеет тип int

 

Был сильно удивлен отсутствием eeprom у обоих... куда настройки писать :( ?

Во флеш, куда ж еще.

[dxp 56]

Почему же личное? Результат операции сравнения имеет тип int

Какой операции? && - этой?

[_Pasha 0]

Какой операции? && - этой?

Я о том, что

if(bool1 && bool2)

является сокращенной формой записи

if((bool1 != 0) && (bool2 != 0))

и в итоге результат && становится int, т.к. операнды int по стандарту

Разве не так?

[dxp 56]

Я о том, что

if(bool1 && bool2)

является сокращенной формой записи

if((bool1 != 0) && (bool2 != 0))

и в итоге результат && становится int, т.к. операнды int по стандарту

Разве не так?

Думаю, что нет. Оператор if принимает уже логическое выражение, к которому сводится арифметическое, т.е. когда доходит принятия решения, то анализируется уже результат выражения в виде "истина/ложь". Поэтому:

 

bool && bool -> true/false && true/false -> true/false.

 

А арифметические выражения в операторе обрабатываются по схеме

 

<арифметическое выражение> && <арифметическое выражение> -> true/false && true/false -> true/false.

 

Т.е. почти также, но чуть сложнее - надо само арифметическое выражение привести к результату в виде "истина/ложь", тогда как в случае явных bool'ов это есть сразу. Сам анализ результата технически одинаков на большинстве платформ, но это уже детали реализации.

 

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

[Itch 0]

Интересно, каким вообще боком относится тип bool к типу микроконтроллера (AVR/ARM/x86/x64 etc.)?

Понятно, что хочется блестнуть знанием С, но тема ведь не про это.

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

И ARMы эту нишу никогда не займут. Ну не нужно для какого-нибудь терморегулятора 32 битное ядро! Им нужно делать PLL, больше возни с программаторами, большее потребление, больше (а значит страшнее для новичка) даташит... Минусы опять же можно долго перечислять.

[IgorKossak 0]

Itch, Вы привели пример типично религиозного мнения.

У любимой платформы - плюсы, у нелюбимой - минусы. Причём, многие утверждения - явно устаревшие. А узнать более свежие сведения мешает всё та же религиозность.

[Itch 0]

Мы здесь говорим о вынужденном переходе с AVR на ARM из-за веяний моды. Когда в кармане в сотике гигагерцы и мегапиксели, то как-то стремно становится иметь 64 байта оперативной памяти. Но это кому как. Мне вот не стремно. Много раз надо было собрать для дома кое-какие вещи. Просто брал простую AVRку и навесным монтажем ее запаивал, даже ПП не делал, из внешних деталей - только один конденсатор по питанию. И все работало, никаких проблем! Зачем мне переходить на ARM?

[demiurg_spb 0]

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

1. Выделение битового пула

Это весьма спорное утверждение. Битово-адресуемая память имеется далеко не у всех контроллеров. Вот у кортекса-м3 эта фишка есть с его 4ГБ (или 32Гб, подзабыл немного - скорее 4ГБ т.к. 2^32=4ГБ) адресным пространством это нормально. А у того же АВР придётся заботится об атомарности доступа к таким битовым полям. Что сильно испортит всю малину. Я ещё на заре своей программистской деятельности под АВР тоже "оптимизировал" флаги и паковал их по 8 штук в байт. Но потом быстренько прозрел. И теперь один флаг - один байт. Компиляторописателям есть чем заниматься и так...

Зачем мне переходить на ARM?

Вам не надо:)

[zltigo 1]

Много раз надо было собрать для дома кое-какие вещи. Просто брал простую AVRку и навесным монтажем ее запаивал, даже ПП не делал, из внешних деталей - только один конденсатор по питанию. И все работало, никаких проблем! Зачем мне переходить на ARM?

Читаем первый пост:

Видимо, АВРки уверенно смещаются в зону "радиолюбительства"

P.S.

А "сведения" из мира НЕ AVR у Вас устаревшие все :(

[Itch 0]

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

1. Выделение битового пула

Надо запаковать bool - используйте union. Но зачем?! Если идет разговор о гигагерцах и мегапикселях то там уже заниматься подобной чепухой не остается времени, да и смысла тоже.

 

А "сведения" из мира НЕ AVR у Вас устаревшие все

SAM7Sxx - не такой уж и старый.

Вообще, мысли об ARM посещают, но сразу с прицелом в линукс. Однако полноценный MMU + контроллер TFT редко где встретишь, даже в контроллерах с ARM9-ядром.

[Борив 0]

AVR-ки если и смещаются, то в сторону классики микроконтроллеров. Туда-же где находится 51 архитектура. Благодаря удобству программирования, отладки, схемотехнике, уверен, что они будут жить очень и очень долго. Задач для них -море.

[aaarrr 69]

SAM7Sxx - не такой уж и старый.

Проблема не в том, что старый (а он все-таки старый), а в том, что это одна из "первых ласточек". Хуже только 7A.

 

Вообще, мысли об ARM посещают, но сразу с прицелом в линукс. Однако полноценный MMU + контроллер TFT редко где встретишь, даже в контроллерах с ARM9-ядром.

Из одних атмелов: AT91SAM9261(S), AT91SAM9263, SAM9G10 - мало?

[dimka76 59]

Видимо, АВРки уверенно смещаются в зону "радиолюбительства"

 

А в чем разница между радиолюбительством и нерадиолюбительством.

В наличии или отсутствии печатной платы? Или в том кто ставит задачи: руководство или сам себе ? Или какой-то научный подход к решению задачи ?

Большинство того, что мы делаем на работе, можно делать и дома.

И наоборот. Очень часто то, что приходиться делать на работе, больше смахивает на радиолюбительство.

 

Так где же грань между радиолюбительством и нерадиолюбительством !?

[demiurg_spb 0]

Так где же грань между радиолюбительством и нерадиолюбительством !?

В серийности и ответственности перед покупателями...

[dimka76 59]

В серийности и ответственности перед покупателями...

 

Есть предприятия, которые выпускают единичные изделия. А что вы сами к себе относитесь безответственно?

Если электронику воспринимать как хобби, то, по определению, она должна приносить удовольствие. А разве будет приносить удовольствие изделие (сделанное для себя), которое постоянно ломается или глючит?