1. среда разработки (компилятор/транслятор)

[beer_warrior 0]

2 DXP

Все верно, однако...

Не вижу я большой в этом беды.

Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?

Ну да в *printf(), ну так сколько об этом говорено.

С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?

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

Чем мне нравиться gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок. Но это, как я уже говорил, дело вкуса.

[defunct 0]

2 DXP

Все верно, однако...

Не вижу я большой в этом беды.

Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?

Ну да в *printf(), ну так сколько об этом говорено.

С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?

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

Чем мне нравиться gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок. Но это, как я уже говорил, дело вкуса.

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

 

 

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

[beer_warrior 0]

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

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

в gcc надо с этим шаманить.

[dxp 65]

2 DXP

Все верно, однако...

Не вижу я большой в этом беды.

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

 

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

 

Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?

Ну да в *printf(), ну так сколько об этом говорено.

С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?

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

 

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

Чем мне нравиться gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок. Но это, как я уже говорил, дело вкуса.

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

[beer_warrior 0]

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

Спорю. Не всегда.

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

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

Дело в том, что gcc в 90% случаев просто не даст собрать кривой код.

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

[dxp 65]

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

Спорю. Не всегда.

Мне очень часто приходиться переносить код с других компиляторов под gcc, и работу и либы, так вот - после всего этого CV и ImageCraft я за серьезные продукты не считаю.

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

 

С IARом же бабушка надвое сказала - может быть выигрыш и в ту и в другую сторону - зависит от конкретного кода. defunct уже привел пример с USB драйвером.

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

 

Дело в том, что gcc в 90% случаев просто не даст собрать кривой код.

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

 

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

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

 

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

[zltigo 2]

...любой компилятор, выполняющий требования Стандарта, будет примерно одинаково реагировать на кривой код - либо ругаться на ошибки, либо генерировать код с неопределенным поведением.

Именно так дело и обстоит - могу свидетельствовать после многолетней работы на разных платформах под разными компиляторами.

Ну а сравнивать реакцию на 'кривой' код можно только при всех активизированых warnigs и remarks.

Практически весь сыр-бор разгорается из-за какого-то проекта с задваленными warnings и нюансами

трактовки warning/error конкретным компилятором.

[Bill 0]

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

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

[dxp 65]

1001-й "бенч мак" намечается ...

 

вот такой тест покатит ?

 

http://www.atmanecl.net/EnglishSite/CCCE.htm

 

 

 

=======

 

это кстати IDE на основе GCC. С встроенным генератором начального кода.

 

и CVAVR там не плохо смотрится.

Там откровенный гон приведен. 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

 

Ее вывод:

   text    data     bss     dec     hex filename
    258       0       0     258     102 slon.o

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

 

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

 

text    data     bss     dec     hex filename
130       0       0     130      82 slon.o

 

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

 

   text    data     bss     dec     hex filename
    310       0       0     310     136 slon.o

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

 

118/130 - 10%

110/130 - 15%

 

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

 

Т.е. Вы - укротитель кода, мегаалгоритмист, который за счет крутого стиля сделает любого другого даже на более слабом инстументе?

Ага, а я - недоделок гонорной, который прогу перенести с одной платформы на другую не в состоянии. Мерси за оценку. smile.gif

Зря вы так.

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

 

По простому - если я знаю, что мой компилятор в каких-то моментах слаб, я избегаю таких моментов, если знаю что силен я такое решение предпочту. Все зависит от кода.

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

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

[Zaicev 0]

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

[beer_warrior 0]

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

 

# 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.

[Nanobyte 0]

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

[defunct 0]

> при оптимизации по скорости 182 слова.

182*2 = 364 байта.

что более чем втрое больше кода, сгенерированного IAR'ом и

почти втрое больше кода сгенерированного gcc (-02 не лучшая оптимизация).

 

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

ICC с оптимизацией (естественно с 32 бит double) - 21 702 байт

[SapegoAL 0]

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

 

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

 

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

[defunct 0]

А каким образом Вы NOP в проект на C подключали? Может в этом кроется ошибка?

 

asm("nop")?