Я знаю, что на этом форуме присутствуют люди, которые не только глубоко знают GCC и, в частности, WinAVR, но и участвуют в той или иной мере в совершенствовании этих продуктов. Поэтому в первую очередь мой вопрос к ним. Я понимаю, что мои вопросы почти риторические, но беспокойство от них у меня сильное...

Скачал WinAVR-20081205 (до этого был 20080610), провел тест на проекте для AT90CAN128. Было 18204 байт результрующего кода (WinAVR 20080610), стало 18350 байт. Исходник не менял, естественно, как и все параметры сборки проекта. Ранее при переходе с 20080411 так же было замечено увеличение итогового кода для проекта. То есть я делаю вывод, что от релиза к релизу GCC генерирует все менее и менее компактный код для AVR (про другие платформы не скажу, ибо не пользуюсь). Неоднократно были замечены всякие странные фокусы при сохранении регистров в прологе функций, некоторые "чудеса" оптимизации и "странности" в обработчиках прерываний (заглядываю на AVR Freaks)...

Что это? Целенаправленное стремление снизить качество GCC для AVR, косвенные следствия каких-то неведомых мне улучшений, непредвиденные последствия исправления багов или что-то еще? Казалось бы, добавилась поддержка новых микроконтроллкров - и на тебе: поддержка старых ухудшилась... Чего ждать в будущем? Единственный качественный бесплатный компилятор - неужели он обречен?!

Может быть, есть какие-то рекомендации по борьбе с такими особенностями? скажем, какие-то ключи компилятора или еще что-то, что позволит получить хотя бы прежний код с новым компилятором?

P.S. Пожалуйста, не надо ответов типа "хотите бесплатно - жрите, что дают!"... Ведь смысл бесплатного продукта не в том, чтобы унизить и заставить жрать помои...

Когда я "находил 10 отличий", дело было в более агрессивном разворачивании функций и небольших циклов в инлайны. Кроме того, сохранение регистров при входе в main() и их восстановление при выходе (т.е. никогда) для моих приложений не нужно. Это все отключаемые вещи. Видимо, набор настроек по умолчанию пока еще не устоялся.

с моей точки зрения, сохранение чего бы то ни было при входе в main() для AVR без ОС - это вообще никогда не нужно! логичнее было бы сделать опцию именно для включения сохранения контекста main() для всяких многозадачных ОС... все-таки для AVR это скорее исключение, чем правило. и, кстати, как пролог main() отключить?

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

Я делаю так, как делать нельзя   только потому, что main() никогда не содержит локальных переменных в своем теле. В более общем случае надо указывать атрибут OS_main  http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00283.html 


Была тема недавно, сейчас не могу найти:
1.Поиграться со значением штрафа --param inline-call-cost
2. Не брезговать квалификатором static для местных локальных функций
3. В особо мистических случаях - явно указывать __attribute__((noinline)) до выяснения причин излишней инлайнизации. 

4. -fno-unroll-loops это запретить разворачивать циклы

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

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

про OS_main уже встречал где-то здесь, однако, в официальный релиз этот патч не вошел? в документации нет ни слова...

Вот что интересно - на небольшом проекте с scmRTOS (около 10килобайт) 20081205 выигрывает у 20071221, а этот выигрывает у более ранних - байт по 100-150. И при этом наблюдается небольшое уменьшение потребления стека.

А на старых добрых С-шных проектах - устойчивый рост.

Похоже, дело в изменениях в самом gcc - в процессоронезависимой части.

Кстати, avreal при компиляции 3.4.2 и 4.2.0 тоже растёт в объёме. Но там 100 килобайт или 110 - никого не волнует.

Итого:
(18350-18204)/18204 = 0,8%
Стоит ли паниковать?
Как говорится, тяжело менять, ничего не меняя, нельзя приготовить омлет, не разбив яйца, на всех не угодишь и т.д.
В конце концов, никто не запрещает Вам пользоваться старой версией или собрать новую под свои личные потребности.

перенос основного акцента в сторону С++ ?

Кстати да, в отличие от MSPGCC, который навсегда остался в 3-й версии GCC, avr-gcc развивается синхронно с общим проектом. Что, по-моему, является большим плюсом.

Кстати, на младших контроллерах очень полезно включать такую вот опцию:

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

P.S. не надо про ассемблер для тини - я в курсе

Я добавил последний AVR-libc  в 20071221. Держу на всякий случай, т.к. к нему вообще никаких претензий не было.





СтоИт в аврстудии по умолчанию

а в чем смысл? в младших контроллерах все вызовы и так короткие (rcall)... -Wl,-relax помогает не хуже

Хорошо. Перефразирую. На контроллерах где по-умолчанию не rcall бывает полезно и причём весьма. Вот только сейчас попробовал на мега16 размер программы уменьшился на 120 байт.
Прикол. А если одновременно и -mshort-calls и -Wl,-relax, то ld падает с сообщением "ld.exe application error"

на моем проекте -mshort-calls вообще не сработала - кучу ошибок при линковке выдало... а вот -relax действует, причем более аккуратно: на маленьких МК не вредит, на больших - помогает, причем существенно (и по скорости тоже выигрыш будет!)

Потому что должен быть один модуль с длинными вызовами и большинство с включенным -mshort-calls , но это неудобно, конечно.

Хочу заметить, что размер кода - не единственно возможный критерий качества оптимизации. Может может там с оптимизацией по скорости выполнения стало лучше?
Не согласен. Во-первых, для указания компилятору, что из функции (любой, а не только main!) никогда не выполняется возврат, существует специальный атрибут. во-вторых, сохранение регистров, которые потом не будут нужны, не нарушает работу программы, а лишь делает код не таким оптимальным, как мог бы. Обратное же (несохранение регистров, которые впоследствии нужны) нарушит работу программы. Поэтому дефолтным поведением должно быть именно сохранение регистров (если специально не указано, что функция noreturn).
Предлагаю гвоворить более конкретно: вот пример кода, вот результат компиляции gcc такой-то версии с такими-то опциями, а вот - другой версии. Или с другими опциями. Вот анализ арботы оптимизатора. А так - совершенно беспредметный разговор получается...

У меня странная проблема на большом проекте 60КБ и mega1281 опция -Wl,-relax приводит к краху линковки...
avr-gcc (WinAVR 20081205) 4.3.2
Linking: ../bin/Paragraph4/Paragraph.elf
avr-gcc -mmcu=atmega1281 -I. -gdwarf-2 -DF_CPU=14745600UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes
-Wa,-adhlns=..............
--output ../bin/Paragraph4/Paragraph.elf -Wl,-Map=../bin/Paragraph4/Paragraph.map,--cref -Wl,-relax
-Wl,-u,vfprintf -lprintf_flt -lm
make: *** [../bin/Paragraph4/Paragraph.elf] Error 1

Проверил ещё на нескольких проектах при добавлении LDFLAGS += -Wl,--relax на некоторых из них происходит крах линкера
(см. картинку во вложенном файле).

Что это? И как быть?

1. в настоящее время меня интересует качество оптимизации именно по размеру, т.е. -Os. до сего момента никогда -O3 не давало в итоге меньший размер кода, чем -Os. в частности, упомянутый проект выдал 30254 байт при -O3.

2. если бы main() не стояла особняком среди прочих функций Си-программы, я был бы готов с вами согласиться. но это особая функция, потому для нее вполне можно по умолчанию использовать особые режимы генерации кода. тем более для AVR, для которых наличие ОС, вызывающей main(), все же скорее исключение, чем правило.

3. к сожалению, я установил новый WinAVR поверх старого, и пока что не спешу делать откат - возможно, все решится меньшей кровью. потому могу сравнивать только то, о чем уже сказал: есть результат компиляции проекта с опцией -Os без других специальных мер старым WinAVR, и есть новый WinAVR, дающий с теми же опциями проекта худший результат. теперь идет поиск опций, позволяющих добиться прежних результатов с новым компилятором.

пока что наибольший эффект дает применение --relax для линкера и -fcall-prologues для компилятора. однако, я очень сомневаюсь, что эти же опции помогут, например, для atmega8 (--relax уж точно не поможет)... а хочется найти универсальное решение проблемы.

Проверте, как влияет на размер кода -fno-split-wide-types.

Анатолий.

влияет: 18278 байт стало. но до стартовых 18204 еще есть резерв этот параметр действует одинаково на всех контроллерах?

demiurg_spb, подправьте свой пост, пожалуйста: ну невозможно пользоваться форумом - все разъехалось вширь донельзя!

Поправил. У меня в фаерфоксе ничего не разъезжалось..
И у меня на 102 байта уменьшилось на 60КБ проекте.
А что этот параметр означает-то? В доке тишина (в WinAVR\doc нет файлов, содержащих этот параметр)...

да.

В этом проекте используются функции для работы с EEPROM из avr-libc?



это паремет GCC и задокументираван в GCC 4.3.3 Manual.

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Упс, опередили.
Т.е. насколько я понял, по умолчанию включено, и это добавляет количество команд mov  вместо movw

Да. Как сторонний эффект.

eeprom.h подключается, но его функции пока не используются.

чем еще можно усушить размер?

На этой странице не встречается "fno-split-wide-types"
Ступил... Нашёл что надо. Спасибо.
Есть дока по "fsplit-wide-types". Теперь совсем неясно стало.
Если разделять по несвязанным регистрам то код должен уменьшаться а тут мы запрещаем split и он уменьшается. Непонятно....
А на мелком проекте 5КБ код вырос на 4 байта

С --param inline-call-cost=4,5,6 игрались?

--param -inline-call-cost

=0.........17902
=1,2,3.....17820
=4,5.......17988
=6,7,8.....18002
=9..........18036
=10,11.....18292
=12.........исходные 18350
при дальнейшем росте значения идет так же рост размера

при этом никакие другие параметры не использовал! комбинация -mcall-prologues -fno-split-wide-types --param -inline-call-cost=1 -Wl,-relax дает 17112 байт! более чем на килобайт меньше отправной точки! (правда, в железе не проверил - работает оно или нет?) :D

это предел? еще хачу!

P.S. интересно, а со старым компилятором сколько бы вышло? проверю обязательно!

-fsplit-wide-types - совершенно очевидно, что в качестве умолчания оно не подходит.

Остальное - так и думал, инлайны

2ARV: -fno-unroll-loops стоИт?

раньше я уже писал: все *loops* опции я пробовал... но проверил еще раз: в комплекте с предыдущим набором 0 байт изменения.

По моим наблюдениям GCC 4.3 лучше чем 4.2 процента на 3. GCC 4.4 будет посередине между ними.

Про -fsplit-wide-types постораюсь вечером расказать.

Анатолий.

Кстати, для тех, кто пользуется максимальной оптимизацией по скорости, рекомендую отключить векторизацию. Не так давно обсуждали этот вопрос.

Буквально сегодня добавил в mspgcc проверку, есть ли выход из функции. Если выхода нет - не сохраняются регистры и не генерится эпилог. Т.е. этакий автоматический __attribute__((noreturn)). Судя по листингу - получается. Даже для main(). Не знаю насколько все изменилось в gcc 4.x по сравнению с 3.х, но можно предположить, что возможность такой проверки осталась - ведь компилятор как-то умеет генерить предупреждения об отсутствии return в функции, возвращающей значения и о наличии точек выхода в функции с атрибутом noreturn. Остается дописать по одному условию в функции генерации пролога и эпилога.

http://electronix.ru/forum/index.php?s=&am...st&p=393663

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


из foo "не должно быть" возврата, поэтому нет смысла после неё восстанавливать стек (собственно, можно было и rjmp нарисовать...)

Аналогично - если у вызывающей функции набралось что-то в caller-save-регистрах, то перед вызовом noreturn-функции она не будет эти регистры сохранять.

а вот еще вопрос (не совсем в тему, но касающийся оптимизации размера): каким образом убрать из кода таблицу векторов прерываний, если прерывания не используются, чтобы "полезный" код начинался с адреса 0х000? актуально для tiny-проектов.

Наверно, подрихтовать скрипт линкера, выкинуть секцию векторов и растянуть кодовую

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

1. качаете исходники avr-libc и распаковываете их;

2. находите заголовычный файл для вашего контроллера avr-libc\include\avr\io<нужный_контроллер>.h, и правите макрос _VECTORS_SIZE, в соттветствии с необходимым количеством векторов. Учтите _VECTORS_SIZE размер таблицы векторов в байтах;

3. компилируете avr-libc;


make install - не делаете;

4. ищете statr-up файл для вашего контроллера build\avr\lib\avr<2,3,....51>\<нужный_контроллер>\gcrt1.o

5. линкуете этот gcrt1.o в ваш проект вместо стандартного.

Анатолий.

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

Пока только так, изменить таблицу векторов можно только в стртап файле.


Анатолий.

слово "пока" зарождает надежду...
а нельзя ли принципиально удалять таблицу векторов, если имеется опция -mno-interrupts ? по-моему, очень логично...