WINAvr или IAR?, для тех, кто работал в обеих средах. Опции

[Karl]

Программирую в WinAvr. Собираюсь попробовать написать новый проект на IAR. В связи с этим вопрос: стоит ли тратить время и силы на освоение IAR? Кто какие плюсы и минусы видит в той или иной среде?

[halfdoom]

С точки зрения качества генерируемого кода IAR безусловно опережает gcc. Буквально неделю назад собрал проект под gcc и iar: gcc 3.4.1 нагенерил 18096, а iar 2.28a 12238 байт. У обоих включена оптимизация по скорости с максимальным уровнем оптимизации. Интересно, что для некоторых функций gcc порождает более компактный код. На практике удобно пользоваться обоими компиляторами, т.к. gcc выявляет большее количество потенциальных ошибок на стадии компиляции. Конечно, это требует написания макросов для поддержки совместимости, что не всегда может быть оправдано.

[ReAl]

С точки зрения качества генерируемого кода IAR безусловно опережает gcc.  Буквально неделю назад собрал проект под gcc и iar: gcc 3.4.1 нагенерил 18096, а iar 2.28a  12238 байт. У обоих включена оптимизация по скорости с максимальным уровнем оптимизации.

GCC при -O3 (максимальная по скорости) инлайнит от себя всё, что считает нужным. Но если функция не была объявлена на уровне файла static (а, как показывают мои наблюдения, всё-таки мало кто ставит static пере функциями, которые вызываются только в данном файле), то её "основное" тело остаётся заодно с инлайновоё инкарнацией, что сильно раздувает код.
Кроме того, при -O3 автоматически включается -funroll-all-loops, что тоже сильно раздувает код.

Как правило, достаточно -O2, возможно с некоторыми доп ключами и ручное static inline для нужных коротких функций. В этом случае разница в объёме не в полтора раза, а 5-15%.

Два основных источника:
- прологи/эпилоги функций, gcc использует один стек и ему надо модифицировать каждый раз SPH,SPL, да ещё и с запретом прерываний.
- gcc как правило обращается к глобальным переменным через sts/lds, тогда как зачастую выгоднее по коду загрузить указатель и ldd/std, IAR этого не упускает.

А вот на коротких функциях с малым числом аргументов/локальных переменных (без стекового кадра) gcc действительно зачастую даёт более короткий и быстрый код.

[m16]

Давно избитая тема но сравнение компиляторов всегда почему то однобокое - раз меньший объем кода генерит знач лучший. А если вопрос по другому поставить - чей код быстрее?(меньший по объему код совсем не значит что более быстрый).