Профессионально пишу уже 2 года на ASMе и Cшке(AVR GCC) для AVRок.
На GCC есть одна вещь которая бесит порой. Оптимизатор.
Работаю на уровне Os(высший, by size).
Оптимизирует нехреново. В железе работает, в отладчике на уровне переменных практически не протрассируеш. Только в дизасм смотри.
Так вот этот GCC иногда считает многие участки кода не нужными.

Допустим запускаю ацп конверсию с прерыванием, в прерывании ставлю какой то флаг,
и по флагу этому в цикле, я должен что то сделать. Ну да ладно подробности.
Факт в том что компилятор теряет логические связи, считает участок кода не нужным.
Выбрасывает его, ставит бесконечный цикл.
Бороться с ним конечно всячески можно(извращениями).

Вот хотел спросить, как по части непрокомпилов(непонимании компилятора) IAR ?
При максимальном уровне оптимизации.
Ну и скажите свои за и против IAR.
Просто думаю, стоит его осваивать взамен AVR GCC иль нет.

To Moderators, если в не тот раздел попал, просьба сильно не пинать.

Простите, а Вам знакомо слово volatile?


Даже неологизм изобрели. Нет такого понятия, есть неправильно написанный софт.

Volatile Знаю. Но искать скрытые подвохи по дизасму(а такие бывали) как то не хочется. И все Volatile объявлять тоже не хороше.

Если возможны "скрытые подвохи", значит знаете недостаточно. В 99.999% случаев в ошибке виноват программист, а не "глючный компилятор".

Хм. Интересна ваша логика. Виноват программист. Понятно, что он, если не знает всех подводных камней компилятора.
Вообще то топик я создал о сравнении компиляторов в данном плане. подводных камешков, а не о знании всех подводных камешков конкретного.
Хм. Виноват программист, еще скажите свой компилятор написать.

Да, виноват программист. Но не знает он не "подводные камни компилятора" (которых нет), а просто язык "C".


Нет, достаточно изучить язык и стандарт, которого придерживаются существующие.

У любого нормального компилятора оптимизатор просто обязан вести себя схожим образом. Не нравятся его действия? Отключите оптимизатор.
Или все же почитайте про volatile - что это и зачем нужно.

Ладно. Не буду с вами "ругаться" и пытаться что доказывать что WinAVR не идеален.
Было бы все идеально и безошибочно предсказуемо, IAR бы помер.
HT-PIC например банки у меня путал (очень редко), пока сам не взял за правило прописывать где че будет лежать,
встречались проблемы. А где разместить переменную, как и Volatile, сложно отнести к самому СИ.
Это всего лишь приказ компилятору- ЭТО ТУДА, а не C.

Согласен. Грамотно применяй Volatile да будет счастье в этом мире.

Но Volatile не C, а для оптимизатора. То что любой оптимизатор будет резать че нить, что не понравится, согласен.
Мне интересно сравнение с IAR. Как он понимает сложные конструкции кода

И еще могу добавить. На PIC тоже на Cшке пишу. Там при работе оптимизатора, как не странно, не разу не обрезался код, по его субъективному мнению.
MPLAB C18 на мой взгляд вообще отличная вещь. Подвохов от вообще нет.

Оптимизатор будет "резать" строго в соответствии со стандартом и только. Кто-то "режет" хуже, из-за чего могут "работать" и те
программы, которые по причине ошибочного построения работать не должны.
У IAR'а с пониманием все в порядке, не сомневайтесь.


Как раз случай недоработки оптимизатора. Нет у компилятора "субъективного мнения", он не разумен.

Приведите пример, что у Вас WinAVR несправедливо режет.

Безвыходных случаев с WINAVR не было.
Всяческими способами я его заставлял понимать как надо.

Ну, если сравнивать IAR и GCC, то с ИАРом у меня отношения хуже складываются (для MSP430).
Полного взаимопонимания нет.
Иногда неправильно отрабатывает if, и на раскопки причины уходит несколько часов.
Наверно, это таки моя вина, а не компилятора, однако факт.

Могу только поддержать aaarrr - у Вас действительно обычные проблемы с выражением мыслей на 'C'. Поиски "правильного" компилятора бесполезны - 99,9% Ваших проблем не в компиляторе .

 

Ну не знаю, за свое недолгое общение с этим продуктом (около года), были найдены баги компилятора (неправильное отрабатывание битового поля нулевой ширины, предупреждения при преобразования указателей к const void* и т.п., всего уже не помню). Хорошо что служба поддержки на это реагирует, хоть и не с первого раза 

В других компиляторах ничего не нашёл

Нет ничего идеального. Все создается людьми. Другое дело, что коммерческий IAR может быть лучше по некоторым критериям, чем бесплатный GCC. Просто рабочий коллектив получает за работу деньги и не один день специализуруется в отрасли средств разработки.
Уважаемый IXFN50N80Q2! А что Вы хотите сказать? Может быть приведете кусочек кода с листингом?

...уверяю Вас IAR в таком случае порежет не хуже.

Задача компилятора - перевести описание с языка, понятного человеку (ЯВУ), на язык, "понятный" МК или CPU, используя формализованные правила. Причем формализованные правила составляет тоже человек или группа людей, те, которые компилятор писали. Если в дилемме: кто был первым яйцо или курица?, то бишь что первично компилятор или программист, его использующий?, считать первичным компилятор, то так и выходит - в 99,9% виноват программист, который не прочитал, не понял или недопонял правила по которым работает компилятор. 0,1% отнесем на ошибки, допущенные теми, кто писал компилятор или документацию для него, т.к. никто полностью от ошибок не застрахован.
Использование квалификатора volatile для описания глобальных переменных, модифицируемых в прерываниях, это всего лишь начальные азы понимания о том, по каким правилам работает компилятор. Но ради справедливости стоит уточнить, что на эти "грабли" наступает очень много начинающих программировать на Си, которые бегло прочитали стандарт Си, но не удосужились прочитать документацию на используемый ими компилятор. Поэтому программа вида

практически всегда будет компилироваться так, что оператор while скомпилируется в "вечный цикл", вне зависимости от правильности инициализации/функционирования таймера и описания функции обработчика его прерывания. А чтобы этого не произошло обычно достаточно пояснить компилятору, что именно вы от него хотите, объявив переменную cntr как

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

Точнее порежет больше, по определению...

То есть чем лучше оптимизирует компилятор, то есть чем он лучше, тем больше он найдёт кусков кода которые бессмыслены. А соответственно он их выкинет.

Соответственно писать надо правильно.

Вы сами посудите... Есть у вас код к примеру...

flag=0;
for(;;)
{
if(flag)break;
}

А флаг устанавливается в каком-то постороннем прерывании. Прерывание, с точки зрения компилятора, просто процедура.
Откуда компилятор знает есть у вас прерывание или нет, разрешено оно или нет... Оно вообще может быть написано на ассемблере или на паскале и прилинковано на этапе сборки... То есть компилятор может вообще не знать о наличии движения по данной переменной.
И что сделает нормальный компилятор (например IAR) - он выбросит и этот цикл да и вообще весь текст ниже цикла. Ну и сообщит, что текст ниже "не имеет смысла". Если вы эту переменную объявите volatile, то этого не произойдёт.

И volatile - это не указание оптимизатору. Это указание что переменная является "внешней". Это надо понимать.

Представьте что у МК единое адресное пространство (целый ряд процов). И переферия, соответственно, читается не "особой" командой, а так как ячейка памяти. Да даже возьмите туже ATMega8515 и к внешней шине памяти прицепите какое нибудь внешнее устройство. Допустим это таймер с адресом 0xfff0. С точки зрения компилятора - обычная ячейка памяти. Теперь, для этой ячейки памяти операция типа extifr=extifr; будет иметь смысл. А для внутренней памяти - абсолютно бессмысленна, и её можно оптимизировать. И как их различить?

Могу согласится, но с тем уточнением, что в стандарте Си многие правила недостаточно конкретизированы. А конкретная реализация их как раз в компиляторе проявляется.