[ViKo 1]

О, видимо, так!

http://www.keil.com/support/man/docs/armcc/armcc_chr1359124934478.htm

Надо попробовать. Это я удачно спросил.

[jcxz 241]

11 минут назад, ViKo сказал:

О, видимо, так!

http://www.keil.com/support/man/docs/armcc/armcc_chr1359124934478.htm

Надо попробовать. Это я удачно спросил.

Возможно, про кейл не знаю, но думаю он тоже должен уметь.

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

[ViKo 1]

1 минуту назад, jcxz сказал:

Возможно, про кейл не знаю, но думаю он тоже должен уметь.

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

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

[jcxz 241]

Только что, ViKo сказал:

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

Лучше все. А косяки почистить. Когда я хочу максимальной оптимизации, ставлю эту галку на весь проект (несколько МБ исходников) и он нормально собирается.

[ViKo 1]

5 минут назад, jcxz сказал:

Лучше все. А косяки почистить. Когда я хочу максимальной оптимизации, ставлю эту галку на весь проект (несколько МБ исходников) и он нормально собирается.

Не, не все. Меня, например, терзало, что я инициализацию периферии микроконтроллера раскидываю по разным файлам, а использую лишь однажды в начале программы. Вот её и сгруппирую.

И остальное - аналогично.

[xvr 12]

2 hours ago, AlexandrY said:

А вопрос в том почему компилятор C сразу все не оптимизирует по максимуму, как делается с современных языках? 

По 2м причинам:

1. Иногда хочется отлаживать откомпилированную программу. Отладка круто оптимизированного кода в дебагере - это занятие для настоящих мазо джидаев
2. Компиляторы тоже пишут люди, и им свойственно ошибаться. Оптимизатор - это гораздо более сложная вещь, чем простой кодогенератор, и накосячить в нём очень просто (а ловить эти косяки потом - очень сложно). Так что иногда приходится отключать :(

 

[one_eight_seven 6]

1 hour ago, xvr said:

По 2м причинам:

1. Иногда хочется отлаживать откомпилированную программу. Отладка круто оптимизированного кода в дебагере - это занятие для настоящих мазо джидаев
2. Компиляторы тоже пишут люди, и им свойственно ошибаться. Оптимизатор - это гораздо более сложная вещь, чем простой кодогенератор, и накосячить в нём очень просто (а ловить эти косяки потом - очень сложно). Так что иногда приходится отключать :(

Alexandry любит неконкретные термины и свистелки с перделками - главное, чтобы модно, стильно, молодёжно. Потому, вопрос задан некорректно.

В первую очередь нужно определить, что есть "оптимизирует по максимуму"?

Например, в GCC есть уровни O2 и O3 - кто из них "по максимуму?"

Обычно используют уровень O2, и даже отлаживать рекомендуют сразу с ним. Более того, рекомендуют даже в релиз собирать с ключём -g, что генерирует отладочную информацию, при этом, GCC её хранит отдельно от кода. Поэтому, при выдаче в релиз отдельной утилитой вся отладочная информация убирается.

Теперь о причинах выбора O2 вместо O3.

1. O3 включает аггрессивный инлайнинг, что не позволяет компактно разместить инструкции в кэше, растёт количество промахов и резко падает производительность.

2. O3 может сломать ABI.

И ничего про удобство отладки.

Изменено 27 декабря, 2018 пользователем one_eight_seven

[Grizzly 0]

3 минуты назад, one_eight_seven сказал:

O2 и O3 - кто из них "по максимуму?"

А есть еще Ofast, в ICC еще и fast :)

[one_eight_seven 6]

5 minutes ago, Grizzly said:

А есть еще Ofast, в ICC еще и fast :)

Есть. Тем не менее, это не объясняет, что из этого "по максимуму" : )

[ViKo 1]

А еще есть Os и Oz.

[one_eight_seven 6]

2 minutes ago, ViKo said:

Oz

О, вот это для меня что-то новое. Что делает? А-то машины с последним GCC, чтобы man почитать у меня рядом нет. А тут: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html об этом молчат. Хотя, гугла намекает, что это в clang'е.

[ViKo 1]

Это для ARM Compiler V6.

http://www.keil.com/appnotes/files/apnt_298.pdf

Чисто по размеру.

[Grizzly 0]

37 минут назад, one_eight_seven сказал:

clang'е

Да, это шланговское и для его отродий.

[jcxz 241]

2 часа назад, ViKo сказал:

Не, не все. Меня, например, терзало, что я инициализацию периферии микроконтроллера раскидываю по разным файлам, а использую лишь однажды в начале программы. Вот её и сгруппирую.

И остальное - аналогично.

Сейчас протестил результат компиляции (с полной балансной оптимизацией) с включённой и выключенной галкой мультифайловой компиляции:

При включении мультифайловой компиляции, загрузка процессора в одном режиме работы прибора даже выросла (с ~8.8% до ~9.2%), в другом режиме работы прибора - снизилась (с ~16.1% до ~14.4%).

А вот суммарный размер образа во флешь при включении мультифайловой компиляции увеличился с 122909+18343=141252 байт до 114617+33871=148488 байт (первое слагаемое - размер кода, второе - размер RO-данных).

Ещё странно, что при включении мультифайловой компиляции, размер RW-данных уменьшился. Хоть и немного: с 80350 до 80318 байт.  

Так что ещё не факт что получите то, что желаете.

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

15 часов назад, AlexandrY сказал:

Почему ахинея без volatile РАБОТАЕТ хотя и не ДОЛЖНА? 

Потому что без оптимизации работа компилятора со всеми переменными аналогична работе с volatile-переменными (взял, посчитал, положил на место).