Я знаю, что на этом форуме присутствуют люди, которые не только глубоко знают 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 действует, причем более аккуратно: на маленьких МК не вредит, на больших - помогает, причем существенно (и по скорости тоже выигрыш будет!)