avr-gcc и IAR, сравнение, но не холивар Опции

[zhevak]

(Предыстория. Можно пропустить.)
Я чуть боле двух лет как перебрался на Линукс. Оставил в покое Венду и Вендовые компиляторы. Все хорошо, полет более чем нормальный. Не сочтите за рекламу! Сижу в Ubuntu (и Debian). Просто после Венды мне показалось, что Ubuntu легче освоить, чем другие Линуксы типа Gentoo и Slackware. Тем более столько народа в ней сидит. И тем более, что средства для разработки программ для AVR уже лежат готовые в репозиториях. В общем, живу и в ус не дую.

Но меня давно подмывало произвести ревизию бинарного кода, который компилится avr-gcc, и сравнить его с IAR-овским кодом. Но все как-то не получалось сделать. То проект был не большой (типа "хелловорлд" в исполнении светодиодов), и поэтому полноценного сравнения не могло получиться. То проект наоборот был большой, и не хватало времени на его портацию в другую среду. А то проект коммерческий -- типа нельзя публиковать. В общем, все как-то не стыковалось с моими чаяниями.

И вот, внезапно выпало счастье заняться небольшим "не засекреченным" проектом. Я его начинал создавать на Mega48. Но в какой-то момент, по мере его роста не хватило флеши, пришлось перебираться на Mega8. Бывает. Не проблема! Переписал. Все легко поднялось и заработало. И на второе счастье у меня оказались свободными выходные (уже прошедшие). Чем я и воспользовался.

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


(А вот теперь по делу.)
Понятно, что поскольку компиляторы разные, они и должны создавать разный по объему код. Если размер кода (бинарник) чуть-чуть превышает 4КБ, то, как вы думаете, какая разница будет в объеме сгенерированных компиляторами кодов?

Я ожидал получить разницу в размере кода ну 100, ну 200 байт. А получил аж 1200 байт. Солидный кусок! Так сильно gcc меня еще не опускал. Обидно, да-а?

Конечно, на мое впечатление еще оказал воздействие тот факт, что если бы я изначально писал под IAR-ом, то мне бы не пришлось по ходу менять проц. Но ведь сам выбрал Линух и gcc!

Но это все эмоции. Мне же интересно было разобраться с состоянием дел вообще. Сначала я засел за оптимизацию. Начал перебирать различные комбинации ключей в надежде как можно более сильно сократить код и под gcc, и под IAR-ом. Да. Мне это удалось сделать. Код немного ужался и там, и там, но все равно разница в килобайт с хвостиком сохранилась: один компайлер генерит код размером в 2596 байт, другой -- 3772 байта. Я оцениваю размер кода по hex-файлу, который непосредственно заливается во флешь. Т.е. здесь вообще без дураков, которых можно обмануть не посчитав, допустим, размер таблицы векторов. Или опустив размер вспомогательных (ну или как их правильно-то назвать?) функций, который компилятор сам может создавать, увидев повторяющиеся участки кода.


(Вопрос.)
Коллеги, не впадая в безумие священных войн, вы можете помочь установить истину в работе компиляторов -- почему они дают такой существенно разный результат? Возможно что-то я не правильно делаю. (А это обязательно так!) Но мне, да и многим из вас, хотелось бы знать -- в каком отношении по объему друг к другу эти компиляторы "готовят" код.

Полный код проекта я могу предоставить. Единственная просьба -- по возможно соблюдать одинаковость исходных кодов в обоих версиях (для gcc и для IAR).

Ну, например, в gcc я есть команда для запрета прерываний cli(), и в IAR-е она тоже есть -- __disable_inerrupt(). Это все легко соблюсти. Сложнее соблюсти, допустим, программные задержки. В библиотеке gcc есть функции _delay_us() и _delay_ms(), а в IAR-е таковых нет. Но по жизни очень часто бывает так, что эти в программе без задержек никак. Поэтому я допускаю, что в исходниках для IAR-а, будут использованы приемы типа

Код

#define FCLK (11059200)
#define delay_ms(n)  __delay_cycles((FCLK / 1000) * (n));
#define delay_us(n)  __delay_cycles((FCLK / 1000000) * (n));

Есть еще одно замечание. Исходный текст написан не очень правильно с точки зрения профи. Пока его улучшать не надо! Я поясню. Дело в том, что этот проект не коммерческий, и этот девайс не предполагается кому-то продавать. Кроме того, передо мной стаояла задача: достаточно тупо слепить устройство и установить его в работу, не доводя его до витринного блеска. Поэтому, например, вместо того, чтобы работать с функциями строк из флеша (avr/pgmspace.h), я их тупо прописываю в printf() и не парюсь, что при этом в Оперативе создается их копия. Просто пока не до этого!

В общем, давайте _пока_ не будем трогать исходники. Ибо я хочу посмотреть на возможности компиляторов для среднестатистического быдлокодера, который пишет проги вот на таком вот уровне. А когда мы совместными усилиями получим какие-то цифры, для сравнения компиляторов, вот тогда уже можно будет отрываться и пытаться уникальными для конкретного компилятора приемами уменьшить объем кода.

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


Надеюсь, вы понимаете меня, и топик не съедет в бессмысленный срач.

Пожалуйста, задавайте ваши вопросы.

Прикрепленные файлы

 monitor_iar.zip ( 19 килобайт ) Кол-во скачиваний: 31
 monitor_gcc.zip ( 9.96 килобайт ) Кол-во скачиваний: 48

 

[_Pasha]

Наткнулся на интересную бяку. Для начала, убрал все "ньюансовые" флаги. Размер существенно не менялся. Компилер, тсз conventional 2010-0110
Придрался к стремно-длинным прологам/эпилогам в прерываниях. По опыту - это гавновопрос, сделал так (почти на автопилоте)

Код

static void postmessage_prim(msg_t msg);
void postmessage(msg_t msg)
{
postmessage_prim(msg);
}

Соответственно, в прерываниях, поменял вызовы на статик-примитив. Логика железная - статик как на ладони, шохошь то и делай.
Так он, собако, абсолютно это игнорирует и прологи те же. Вот жеж нанизм блин! И самое загадостное, что у мну это много раз так разруливалось. Он что, фамилию спрашиват?

UPD причину нашел, надо было указать __attribute__((pure))
С дефолтовым минимальным принтфом 3788 байт.

[demiurg_spb]

С дефолтовым минимальным принтфом 3788 байт.

аналогично, но у меня поменьше вышло 3424
вообще без правки исходников, лишь переписал Makefile.

CODE

avr-gcc (AVR_Toolchain_3.0_149) 4.4.3
Copyright © 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Building project: bin/monitor-gcctest/monitor-gcc.elf

avr-gcc -mmcu=atmega8 -MMD -MP -MF ./bin/monitor-gcctest/monitor-gcc.dep -gdwarf-2 -DF_CPU=4608000UL -Os -pedantic -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -fno-split-wide-types --combine -fwhole-program -ffunction-sections
-fdata-sections -Wl,--relax -ftree-loop-ivcanon -mcall-prologues -fno-tree-scev-cprop -finline-small-functions -fearly-inlining
--param inline-call-cost=2 -finline-limit=65535 -mshort-calls -fno-unit-at-a-time -Wsign-compare -Wa,-adhlns=./bin/monitor-gcctest/monitor-gcc.lst
-std=c99 -I. hal.c app.c lcd4.c main.c --output bin/monitor-gcctest/monitor-gcc.elf -Wl,-Map=./bin/monitor-gcctest/monitor-gcc.map,--cref
-Wl,--gc-section -Wl,-u,vfprintf -lprintf_min

Creating load file for Flash: bin/monitor-gcctest/monitor-gcc.hex
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature bin/monitor-gcctest/monitor-gcc.elf bin/monitor-gcctest/monitor-gcc.hex

Creating load file for EEPROM: bin/monitor-gcctest/monitor-gcc.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 --no-change-warnings -O ihex bin/monitor-gcctest/monitor-gcc.elf bin/monitor-gcctest/monitor-gcc.eep || exit 0

Creating Extended Listing: bin/monitor-gcctest/monitor-gcc.lss
avr-objdump -h -S bin/monitor-gcctest/monitor-gcc.elf > bin/monitor-gcctest/monitor-gcc.lss

Creating Symbol Table: bin/monitor-gcctest/monitor-gcc.sym
avr-nm -n bin/monitor-gcctest/monitor-gcc.elf > bin/monitor-gcctest/monitor-gcc.sym

Size after:
AVR Memory Usage
----------------
Device: atmega8

Program: 3424 bytes (41.8% Full)
(.text + .data + .bootloader)

Data: 157 bytes (15.3% Full)
(.data + .bss + .noinit)

Последний WinAVR выдал ещё на 4 байта меньше 3420.
avr-gcc (Klen's GCC package (KGP) for AVR/elf platform) 4.6.0 20100725 (experimental) выдал на 30 байт больше 3454

Сообщение отредактировал IgorKossak - Feb 27 2011, 09:45

[zhevak]

... выдал на 30 байт больше 3454

30 байт это 1%. Мне кажется это не существенно.

(что-то все еще никак не могу засесть за свою задачу и заменить printf на более "легкие" функции.)

[zhevak]

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

Я заменил вызовы sprintf() на strcpy_P(). Где -то это оказалось вообще безболезненно (изменения только в файле app.c):

Код

  case MODE_STOP:
//    strcpy(buf0, "    Spectron");
//    strcpy(buf1, " Click for start");
    strcpy_P(buf0, (PGM_P)pgm_read_word(&(str0)));
    strcpy_P(buf1, (PGM_P)pgm_read_word(&(str1)));
    break;

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

Код

  case MODE_0:
//    sprintf(buf0, "Channel 1:%6lu", uvchannel0);
    strcpy_P(buf0, (PGM_P)pgm_read_word(&(str4)));
    buf0[8] = '1';
    ltoa(uvchannel0, buf3, 10);
    len = strlen(buf3);
    strcpy((buf0 + (16 - len)), buf3);

    buf1[0] = 0x00;
    break;

Вот, при такой замене размер секции text даже увеличился с 3400 до 3456 байт, а размер секции data уменьшился со 114 до 86 байт.

Потом я вынес повторяющиеся участки в отдельную функцию:

Код

void preplcd(char *buf, char ach, long uv)
{
  char buf3[12];
  uint8_t len;

  strcpy_P(buf, (PGM_P)pgm_read_word(&(str4)));
  buf[8] = ach;
  ltoa(uv, buf3, 10);
  len = strlen(buf3);
  strcpy((buf + (16 - len)), buf3);
}

оставив на месте только ее вызов:

Код

//    sprintf(buf0, "Channel 1:%6lu", uvchannel0);
    preplcd(buf0, '1', uvchannel0);    

    buf1[0] = 0x00;
    break;

То размер секции text удалось еще ужать до 3420 байт.

Таким образом, размер бинарного кода для загрузки во флеш сейчас составляет 3506 байт.

Резюме всего исследования будет такое:

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

Увы и ах! Я так понимаю, дальнейшие изыскания не приводят к желаемому результату. К сожалению, вынужден признать, что в этот раз gcc "продул" IAR-у. Это вывод №1.

Вывод №2. Замена sprintf на серию функций не дала существенной экономии. На деле даже получился небольшой проигрыш. Но это скорее всего из-за того, что были так же взяты не чистые функции (strcpy), а функции работы с флеш-памятью (strcpy_P). Но так или иначе получается, что раз улучшения нет, то функции printf в libc не такие уж и "раздутые", как казалось ранее. Просто что-то еще улучшить в gcc или libc у их создателей уже не получается. Использовать же printf на практике вполне можно и даже нужно, ибо ясность исходного кода куда более важна, чем экономия 20 байт флеша.

Если у вас есть что добавить или опровергнуть, пожалуйста скажите, я же дальнейшие "исследования" в этом направлении прекращаю. Здесь ловить не чего.

[MrYuran]

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

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

[zhevak]

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

Ну, это уже холивар, от которого я бы хотел отойти. Мне важно не поспорить, а важно найти истину -- важно знать, что и сколько я (лично я) теряю при использовании gcc. А то, что gcc распространяется бесплатно, так это итак все знают. Но сколько при этом теряется "компактности" -- одни слухи и какие-то бездоказательные утверждения. Я, так сказать, пожертвовал своим временем и своей репутацией (вывесил сушиться свои трусы на площади). Я думаю, что народ понял мой поступок, поэтому давайте по существу. Иначе мы так и будем продолжать жить эмоциями, а не фактами.

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

Если Вас, MrYuran, это хоть как-то успокоит, то знайте, что я сожалею о "проигрыше" gcc, но тем не менее, остаюсь с ним. Как я уже где-то выше говорил, я не использую Венду вообще. Поэтому у меня нет выбора. И даже если бы сидал под Вендой, то использовать пиратский IAR мне претит мое воспитание. И тут дело даже не в неотвратимости наказания за пиратство. Тут более высокие понятия. Дети будут ржать, но все же скажу -- дело в морали. Дело в ответе на тот самый главный вопрос -- а для чего мы вообще живем. Каждым человеком движет получение удовольствия. Мы все получаем удовольствие. Только один получает удовольствие от того, что имеет много денег, а другой -- от того, что много знает и много чего умеет делать. Мне нравиться второе. Плюс, я еще это положение "дожимаю" понятиям типа "жить, оставаясь в рамках морали". (Не в рамках закона, а по совести -- почувствуйте разницу!) Мне это интересно, и я от этого получаю удовольствие. А деньги -- что! Деньги -- фигня! Сколько бы их ни было, их всегда не хватает. Определитесь со своим главным вопросом, и все придет в норму. Я никого не осуждаю. Просто каждый сам отвечает на это вопрос по-своему, а как правильно -- никто не знает.

Блин. На хрена я это все написал?
Ладно. Пусть будет. Может сгодится кому еще.

[zltigo]

использовать пиратский IAR мне претит мое воспитание.

Вы, наверное, не поверите, но IAR можно купить. Не всегда стоит экономить на инструментах. Заодно не придется юродски коверкать названия продуктов.

[zhevak]

Вы, наверное, не поверите, но IAR можно купить. Не всегда стоит экономить на инструментах. Заодно не придется юродски коверкать названия продуктов.

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

Заодно не придется юродски коверкать названия продуктов.

Э-э... извините, вот тут я вообще ничего не понял. Это Вы про что?

[IgorKossak]

Э-э... извините, вот тут я вообще ничего не понял. Это Вы про что?

Это про Венду, очевидно. И давайте замнём этот вопрос.

Модератор.

[demiurg_spb]

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

[zhevak]

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

Спасибо за критику.

Пинать продукты? Да, собственно, никто и не думал пинать. Есть исходный текст проекта, который реальный, а не гипотетический. Не идеальный (а что, разве в жизни все проекты идеальные?) На этом проекте мы поигрались. Получили какой-то результат. Я вообще не вижу никаких проблем.

Единственная проблема состоит в том, что я захотел самостоятельно на своем проекте убедиться для себя лично кое-в-каких цифрах. Да, я и не говорю, что я очень хорошо знаю язык, среду разработки и прочее, что влияет на объем и качество кода. Знаю их на каком-то своем уровне. Этот уровень меня минимально устраивает. Я делаю свою работу и как могу повышаю свою квалификацию. Это плохо?
Ну, ладно, я не подходящая кандидатура. Давайте тогда что-ли найдем идеального товарища, который согласится оставить свою работу, провести всестороннее исследование и ответить на множество вопросов. Но ведь таких людей нет! Они заняты решением своих проблем.

Вот, например, товарищ A (не буду называть его имя) -- грамотный специалист. Давайте его поспрашиваем. Что мы получим? Вместо ответов мы нарвемся на наезды, что мы делаем не то и не так, и вообще не тем занимаемся. Мы о себе много чего узнаем интересного. Но ответ на вопрос -- это уж как товарищ решит, можем и не получить.

Я попытался "испечь торт" из того, что у меня было. Вам не понравилось? Ну что ж... Хорошо. Вы можете чем-то помочь?


Блин, все-таки холливар! Словоблудие.

[demiurg_spb]

Пинят и пинать - два разных слова:-)
Поэтому я и предлагал использовать приличный во всех смыслах open-sourсe проект для таких вот изысканий.
Или даже больше какой-либо синтетический тест из уже существующих.
Изобретение колеса заново - не метод инженера.

[zhevak]

Пинят и пинать - два разных слова:-)
Поэтому я и предлагал использовать приличный во всех смыслах open-sourсe проект для таких вот изысканий.
Или даже больше какой-либо синтетический тест из уже существующих.
Изобретение колеса заново - не метод инженера.

Ну, тогда уж не "пинять" а, "пенять". Извините, я действительно не знал, как понимать Ваши слова.

Ну, давайте, давайте возьмем готовый opensource-проект. Лично я не против. Другие участники, думаю, тоже не будут возражать. Вопрос только в том, кто все это будет делать? Кто все это дело будет двигать? Я не смогу. Вы предложили -- Вы и раскручивайте кампанию, а мы по мере сил Вам поможем и, уж простите, так повелось, -- покритикуем. Ну что, беретесь? Только я буду на вторых ролях, не хочу быть лидером.

MrYuran, да я такого же мнения. Жить с gcc можно. Хотя, признаться, я несколько разочарован, но ведь не смертельно ж! Тем более, что Заказчику как правило, вообще пофиг на чем написано -- хоть на Васике! Лишь бы работало согласно ТЗ, и стоимость разработки не вылезала за бюджет.

[demiurg_spb]

Я готов потестить под различными версиями gcc.
Вопрос в выборе теста остаётся открытым.

Народ, высказывайте Ваши предложения!

[klen]

Я готов потестить под различными версиями gcc.

.... а как я готов!!! готовее меня есть кто ??

предлагаю архитектуру проекта.
0. используем компонентный подход
1. проект представляет собой основной модуль - FreeRTOS
2. далее модули, реализующие часто встречающиеся или не часто задачи из предметной области оформленные в виде библиотек, юзабельные в тестовых задачах FreeRTOS,
3, две версии - одна чистый С, вторая версия смесь С/С++/Fortran пережовывемые компиллеров в едином сборочном проъекте.

что нам это даст.
0.модульность и взаимозаменяймость.
1, при желании практически полную независимость модулй
2, возможность набирать тестовый набор модулей наиболее соответствующему требуемому испытанию.
3, простата измерения размера модулей(возможно напишу утилсу которая лазит по elf и считает то что нужно по отдельности) и их скорости на контрольной трассе (средствами FreeRTOS).
4. комплексная оценка совместной работы с другими модулями и FreeRTOS.

что имею.
0, Шаблон проекта посторенного по вышеописанному
1, готове модули
а) решение системы нелинейных уравнений на С
б) модуль на Фортране реализующий ЧМ демодулятор комплексного сигнала на нулевой промежутке.
в) хороший такой тест шаблонов STL на С++. кстате сам удивился когда оказалось что можно эффективно использовать на микроконтроллерах.
г) могу сделать страницу на своем портале посвещенную всему этому театральному действу, сделать SVN репозиторий для проекта, раздать права на запись наиболее горячмим джигитам, права на чтения "бесплатно"

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

хотелось бы чтоб тема не заглохла а превратилась в феерическое представлнеие траха мозка и отжига - нада ж както отдыхать ....

[demiurg_spb]

FreeRTOS и чистый СИ - не понял как мы это сможем сбилдить с ключиками
--combine -fwhole-program, раз уж мы хотим выжать из gcc по максимуму...

Какие-либо "относительно стандартные" тесты существуют?

Предлагаю из модулей подцепить:
free-modbus
fatfs
и какую-нибудь GUI-библиотечку.

насчёт SVN - одобрям

[MrYuran]

FreeRTOS и чистый СИ - не понял как мы это сможем сбилдить с ключиками
--combine -fwhole-program, раз уж мы хотим выжать из gcc по максимуму...

Скорее наоборот, с плюсами проблемы будут, FreeRTOS на чистом си написан
Хотя опять же не вижу проблемы. Сишные исходники скомпилить оптом с этими ключами, а с++ модуль прилинковать отдельно

[demiurg_spb]

Скорее наоборот, с плюсами проблемы будут, FreeRTOS на чистом си написан

от ScmRtos навелось...

Сишные исходники скомпилить оптом с этими ключами, а с++ модуль прилинковать отдельно

Вы так пробовали? Я что-то сильно сомневаюсь что так можно. Ключик-то называется ВСЯ программа -fwhole-program.
При таком способе компиляции вроде как даже и объектные файлы-то не создаются.

[MrYuran]

Вы так пробовали? Я что-то сильно сомневаюсь что так можно. Ключик-то называется ВСЯ программа -fwhole-program.
При таком способе компиляции вроде как даже и объектные файлы-то не создаются.

Вот, баловался летом...

Код

#
#$(NAME).elf : $(CSRC)
#    @echo $^
#    @$(CC) -c $(CFLAGS) -combine -fwhole-program $^ $(LDFLAGS) -o $(NAME).o
#    $(CC) $(NAME).o $(LDFLAGS) -o $@

Создаётся один обобщённый объектник из пачки исходников, который потом линкуется на общих основаниях