WinAVR-20081205 и тенденции, С каждым релизом WinAVR размер кода растет :( Опции

[ARV]

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

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

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

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

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

[alx2]

Было 18204 байт результрующего кода (WinAVR 20080610), стало 18350 байт.

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

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

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

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

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

[Сергей Борщ]

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

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

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

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