2 DXP
Все верно, однако...
Не вижу я большой в этом беды.
Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?
Ну да в *printf(), ну так сколько об этом говорено.
С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?
Все это небольшое преимущество (?) убьеться на корню просто наличием каких-то левых переменных, лишними вызвами функций итп.
Чем мне нравиться gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок. Но это, как я уже говорил, дело вкуса.

Абсолютно согласнен со сказанным. Еще неизвестно что полезней. Более строгий стиль написания или чрезмерно умный компилятор? А эффективность сгенерированного кода может с успехом быть выше на gcc, тому есть подтверждение даже на этом форуме - пару месяцев назад пробегавшая здесь ветка о USB драйвере для AVR.


На мой взгляд, единственное неоспоримое преимущество IAR состоит во встроенной поддержке 64-битной арифметики с плавающей запятой.

Добавлю, автоматическая генерация lpm, при модификаторе _flash,
в gcc надо с этим шаманить.

А я не утверждаю, что в этом какая-то большая беда. Я лишь спорил с утверждением, что AVR-GCC генерит более компактный и быстрый код нежели IAR. Это совсем неверно, за IAR'ом приоритет. Надеюсь, Вы не спорите с этим тезисом?

В свое время оценивал качество кодогенерации IAR, AVR-GCC и ImageCraft. На первом месте IAR, на втором AVR-GCC, на последнем оказался ImageCraft. Еще народ сравнивал с CodeVision, утверждают, что этот соответствет ImageCraft'у. Таким образом, из распространенных компиляторов для AVR по качеству кодогенерации AVR-GCC прочно удерживает второе место. Почетное второе место - некоммерческому проекту тут с IAR'ом тягаться сложно.


Речь идет не только и не столько о передаче аргументов через стек, сколько об использовании локальных объектов внутри функции. Вот, например, объявлен внутри функции пяток переменных - пара интов, один флоат, мелкая структурка-враппер, которую возвращает одна из вызываемых функций и/или юнион. Регистров на это не хватит - они и так для работы нужны, поэтому разместится это в стеке. И тут нужна эффективная работа со стеком. В IAR'е все прозрачно - Y-pointer непосредственно все это адресует. В случае же avr-gcc компилятор будет производить ту самую подготовку стекового кадра (stack frame) - копирование в критической секции значения SP в Y, модификация SP, чтобы он указывал за пределы выделенного стекового кадра (чтобы было куда адреса возвратов складывать и оно не перемешалось с данными выделенного стекового кадра). Похожую операцию делает, например, комплитор для Blackfin'а, но у этого проца есть специальная инструкция подготовки стекового кадра - link N (где N - размер кадра), для нее есть парная инструкция unlink. А AVR-GCC эти вещи делает сам. Оверхед налицо. И порой не мелкий.


Хороший и высококачественный инструмент - совсем не повод писать безобразный и горбатый код. Код всегда надо писать идеологически правильный, чтобы не было сюрпризов. И еще надо знать "повадки" компилятора, чтобы добиваться устойчивого по предсказуемости результата. Т.ч. тезис "gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок" мне не понятен. Если писать криво, с хаками, использовать код, приводящий к неопределенному поведению и т.д., то при любом компиляторе будет плохо. Если писать грамотно, с пониманием требований языка и особенностей реализации, то при любом компиляторе будет хорошо. Только с IAR'ом будет лучше, чем с AVR-GCC. Насколько лучше и кому это надо - это другой вопрос.

Спорю. Не всегда.
Мне очень часто приходиться переносить код с других компиляторов под gcc, и работу и либы, так вот - после всего этого CV и ImageCraft я за серьезные продукты не считаю. С IARом же бабушка надвое сказала - может быть выигрыш и в ту и в другую сторону - зависит от конкретного кода. defunct уже привел пример с USB драйвером. Я к сожалению примера привести не могу, но как только напорюсь на подобный случай обязательно задокументирую и приведу. Вместе разберем на глазах у общественности.
Дело в том, что gcc в 90% случаев просто не даст собрать кривой код.
По умолчанию он чрезвычайно педантичен. Когда я пару лет назад перескакивал на него с IAR, волком выл - нихрена не работало. Все время в листинг приходилось лазить. Зато через год почувствовал насколько я стал лучше писать. В общем это как ручное переключение передач и коробка-автомат - можно спорить до хрипоты, но налицо просто два разных подхода, дело вкуса.

Если попереносить код с gcc на другие компиляторы, там тоже такого понавылазит, что мало не покажется - там одних gcc'шных расширений до и больше. И будут говорить (и говорят - почитайте архивы su.c-cpp), что gcc дерьмо, писанный в нем код нихрена нигде без доработки напильником не работает. А на деле все упирается в элементарную портабельность. Портабельный код работает везде.


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


Улыбаете. Да куда ж он денется. Приведите пример кривого кода, который компиляется, например, в IAR'е и не компиляется в GCC?


Заблуждение. Я когда начинал писать на том же IAR'е, тоже постоянно в листинг смотрел (благо, листинг у него человеческий, а не как у gcc), и частенько находил там причину не того поведения, которого ожидал. А главная причина этого была в том, что в те времена сам еще тот же С толком не знал. Когда поработал годок-другой, когда скилл подрос, так и писать сразу хорошо стало получаться. Потом то, что пробовал на gcc, все сразу получалось без вопросов. Основные вопросы при знакомстве с gcc были - это дурацкая документация (по сравнению с коммерческими продуктами), дурацкий, запутанный, загроможденный формат файла листинга (после IAR'а так вообще ломало, благо ситуацию можно было несколько исправить применением sed'ового скрипта для удаления лишнего и форматирования оставшегося), оригинальный подход при задании сегментов линкеру - когда там все разные адресные пространства отмаплены на одно, и другие более мелкие вопросы. Но с кодогенерацией и работоспособностью кода никаких проблем уже не было.

Т.ч. не надо тут сравнений про коробки передач, мимо кассы они. Горбатый код на IAR'е точно так же не работает. Посмотрите, сколько вопросов про IAR тут задают, вечно у кого-то что-то не работает (у новичков, по большей части, которые просто еще не научились, и пишут тот самый кривой код). Про gcc вопросов на порядок меньше - косвенно это указывает совсем на обратное, утверждаемому Вами. Конечно, это объясняется в первую очередь, что пользователей gcc гораздо меньше, а новички по больше части западают на более дружественный и простой в основении IAR. Но при прочих равных компиляторы эти по требовательности к качеству исходного кода примерно равны и определяется это следованием Стандарту - любой компилятор, выполняющий требования Стандарта, будет примерно одинаково реагировать на кривой код - либо ругаться на ошибки, либо генерировать код с неопределенным поведением.

Именно так дело и обстоит - могу свидетельствовать после многолетней работы на разных платформах под разными компиляторами.
Ну а сравнивать реакцию на 'кривой' код можно только при всех активизированых warnigs и remarks.
Практически весь сыр-бор разгорается из-за какого-то проекта с задваленными warnings и нюансами
трактовки warning/error конкретным компилятором.

Это было бы замечательно!

Там откровенный гон приведен. IAR мне выдал 118 байт при оптимизации по скорости и 110 - по размеру.

IAR
Командная строка (по скорости):
%IAR%\%AVR%\bin\iccavr.exe slon.cpp -lC slon.lst -e --cpu=m16 -ms -s9 -r -I%IAR%\%AVR%\inc -I%IAR%\%AVR%\inc\dlib --diag_suppress=Pe951

Вывод компилятора:
IAR Atmel AVR C/C++ Compiler V4.12A/W32, Evaluation Version
Copyright 1996-2005 IAR Systems. All rights reserved.

118 bytes of CODE memory
0 bytes of DATA memory (+ 3 bytes shared)

Errors: none
Warnings: none


Командная строка (по размеру):
%IAR%\%AVR%\bin\iccavr.exe slon.cpp -lC slon.lst -e --cpu=m16 -ms -z9 -r -I%IAR%\%AVR%\inc -I%IAR%\%AVR%\inc\dlib --diag_suppress=Pe951

Вывод компилятора:
IAR Atmel AVR C/C++ Compiler V4.12A/W32, Evaluation Version
Copyright 1996-2005 IAR Systems. All rights reserved.

110 bytes of CODE memory
0 bytes of DATA memory (+ 3 bytes shared)

Errors: none
Warnings: none


WinAVR 20060421
Командная строка:
avr-c++.exe -c -mmcu=atmega16 -g -O3 -Wa,-adhlms=slon.lst slon.cpp

Поскольку компилятор не утруждается выводом статистики по размерам использованных данных и кода ни при выводе, ни в листинге, то приходится использовать утилитку:

avr-size.exe slon.o

Ее вывод:

Насколько я знаком с gcc, секция text - это и есть код. Т.е. 258 байт. Что-то много. Оптимизация максимальная.

Снижаем оптимизацию до O2 получаем:



Намного лучше. Другие виды оптимизации дают тот же результат. Без оптимизации:


Совсем плохо. Вывод - работать, видимо, надо с O2. Но такой дикий разброс - в два раза выглядит очень странно! Зато логично выглядит замечание коллеги beer_warrior'а, что с gcc надо держать ухо востро - на IAR'е я выставил максимальную оптимизацию и забыл про проблемы - получаю всегда самый лучший код. А за этим надо следить - как бы он чего не напакостил. Вряд ли это обстоятельство можно отнести к достоинствам компилятора.

118/130 - 10%
110/130 - 15%

Где-то так оно и есть. Хотя по такому мелкому тесту судить, конечно, нельзя.


Прошу прощения за некоторую резкость, но выглядело это именно так.


Это похоже на "моя машина плохо берет подъемы, поэтому в подъемы я стараюсь не ездить".

Пользую GCC в связке с AVRStudio

quote]Совсем плохо. Вывод - работать, видимо, надо с O2. Но такой дикий разброс - в два раза выглядит очень странно![/quote]

# Optimization level, can be [0, 1, 2, 3, s].
# 0 = turn off optimization. s = optimize for size.
# (Note: 3 is not always the best optimization level. See avr-libc FAQ.)[

So generally, it seems -Os -mcall-prologues is the most universal "best" optimization level. Only applications that need to get the last few percent of speed benefit from using -O3.

Большинство проектов выполнял на ASM, из плюсов - максимальное быстродействие, полный контроль над МК, отсутствие проблем с постоянным поиском новых версий компиляторов. Из минусов - бОльший объём исходных текстов. Отладка проводится в основном на живом железе, иногда, в сложных случаях, использую Studio. Для работы с текстом пользуюсь FAR, с расцвечиванием для AVR. Встроенный редактор Studio кривоват (IMHO).

182*2 = 364 байта.
что более чем втрое больше кода, сгенерированного IAR'ом и
почти втрое больше кода сгенерированного gcc (-02 не лучшая оптимизация).

Для теста скомпилировал один из своих проектов с большим числом мат. расчетов в IAR без оптимизации (BEST DEBUG) с поддержкой 64 бит double объем HEX файла - 11 555 байт
ICC с оптимизацией (естественно с 32 бит double) - 21 702 байт

По поводу компилятора. Попробовал переписать на ASM хороший кусок линейного кода IAR C (без использования сложной арифметики). Результат кропотливой оптимизации не превысил 35%. Некоторые куски компилируются в более оптимальный код!!!! Этого я не ожидал.

По поводу AVR123. Я считаю что Вы делаете нужное дело. Не страшно что есть ошибки! Не ошибается тот, кто ничего не делает! А вот рекламы надо поменьше. Все уже от неё устали и поэтому злятся. Переключитесь на время на Точку Опоры. Там новичков побольше. Переговорите с webmasterom Точки Опоры может они Ваш курс включат в свои ссылки. И пожалуйста, не принимайте мои слова за критику, но моё мнение что навигации в Вашем курсе всётаки не хватает. Мало чайников найдётся чтобы запоем читать. А вот отдельные моменты, - это пожалуйста.

На окончательное мнение не претендую.

asm("nop")?