-
- Я давно говорю, при разработке кода, сразу включайте все возможные
оптимизации, в том числе и LTO. Код будет качественнее, так как
увидите больше ошибок и предупреждений по делу. По крайней мере в
GCC (и AVR-GCC 12) так. Nikolay_Po(115 знак., 20.04.2023 14:54)
- включил максимальную оптимизацию (по размеру) - все работает,
ошибок и предупреждений нет. в старой версии компилятора. при
максимальной оптимизации по скорости одна ошибка - памяти не
хватает - Andrey190(20.04.2023 15:17)
- Компилятор у них собственный, яровский? Я такой не использовал ни
разу, только GCC и производные - XC
C, AVR-GCC, GCC для ARM... - Nikolay_Po(20.04.2023 15:35)- вроде да, но это не 100% ) - Andrey190(20.04.2023 15:35)
- Компилятор у них собственный, яровский? Я такой не использовал ни
разу, только GCC и производные - XC
- включил максимальную оптимизацию (по размеру) - все работает,
ошибок и предупреждений нет. в старой версии компилятора. при
максимальной оптимизации по скорости одна ошибка - памяти не
хватает - Andrey190(20.04.2023 15:17)
- Х-м. Тут (вполне возможно) и оптимизация кода сыграла негативную
роль, как водится в подобных траблах. Т.е вполне возможно
разработчики, в сторону FULL пододвинули и... выходной код
"поплыл". Отсюда , кстати вопрос: а на каком режиме оптимизации
компилировался исходник в v7.4. и в v8.10? Если одинаково, то с
выключенной оптимизацией что даёт верификация размера выходных
кодов через эти версии? - SERGHIO(20.04.2023 14:08)
- Очевидно, код поплыл из-за ошибки в программе или из-за ошибки в
компиляторе (последнее маловероятно). - Nikolay_Po(20.04.2023 14:56)
- Да...тут и всё вкупе может статься. И в исходнике и на выходе компилятора. Например в вышеуказанной v7.4 (при тех же настройках) всё ОК! А с тем же, т.с., "тестом" при тех же "добавках" на той же "конфорке", но на другой версии "плиты"/v8.10/ того же производителя и... "блины пошли комом"! А по какой возможной причине? Ну, например, в сторону SERGHIO(946 знак., 20.04.2023 16:29)
- оптимизацию не трогал. но код в 8.10 уменьшился с ~57 до ~48 кБ.
дальше экспериментировать не буду - снес новую версию. новых
проектов на АВР не планирую, а старые подправить и так получится - Andrey190(20.04.2023 14:24)
- Для меня 8.10 заметно "поумнел" после 7.30. Я по большей части "железячник", мой главный отладчик - листинг. Порой, устав воевать и объяснять компилятору, что мне надо, критичные по скорости секции просто писал на ассемблере. Посмотрел листинги после 8.10 - компилятор всё делает сам, как надо. Жонглирует регистрами, ни одного лишнего телодвижения. Конечно, 7.30 оставил, на всякий случай, но пока у меня с 8.10 все отлично (кроме вертикального сплита :)). - vpv.vpv(25.04.2023 07:40)
- Явно компилятор что-то полезное выкинул раз код так сильно
сократился. Вообще храним версии 5 / 6 / 7 и вот теперь 8 во
избежание... - Chip_n_Go(20.04.2023 15:25, )
- printf выбросил, наверное. :-) - Boвa(22.04.2023 05:58)
- за 25+ лет работы с контроллерами, ни разу не использовал printf. да и другие стандартные по минимуму - Andrey190(22.04.2023 08:37)
- Когда кейл51 выпустил 9.6 компилятор - код ужался на 20кбайт - с
60+ (уже в память не умещалось) до 40. Всё прекрасно работает... POV(207 знак., 20.04.2023 15:33)
- я в основном по этой причине и не использую максимальную оптимизацию. пока памяти хватает... - Andrey190(20.04.2023 15:45)
- Это да. Тенденции компиляторостроения таковы, что компилятор лишь обеспечивает эквивалентный вашему коду "побочный эффект". Результат компиляции может не иметь ничего общего с вашей идеей, будет похож на содержимое файла архива, освобождённое от избыточности. Делает невозможной отладку, но будет соответствовать заданным вами "побочным эффектам" - записям/чтениям регистров периферии и других volatile-областей памяти. - Nikolay_Po(20.04.2023 15:42)
- printf выбросил, наверное. :-) - Boвa(22.04.2023 05:58)
- Я бы не удержался, задержался бы на работе, да раскопал бы до конца
- значит, у меня в программе баг, если смена версии компилятора
ломает программу. Сразу обновляю компилятор, как выходит очередной
релиз - и не имею проблем, только времянки время от времени
контролирую диагностикой осциллографом или анализатором, где
критично. - Nikolay_Po(20.04.2023 14:57)
- если бы проект был живой - я бы так и сделал. на проекте который
закрыт пару лет, и где только исправляются найденные ошибки - не
вижу особого смысла - Andrey190(20.04.2023 15:14)
- Дело хозяйское. Меня вот, ругают за нецелевое расходование рабочего времени на старые проекты, да... :) - Nikolay_Po(20.04.2023 15:15)
- если бы проект был живой - я бы так и сделал. на проекте который
закрыт пару лет, и где только исправляются найденные ошибки - не
вижу особого смысла - Andrey190(20.04.2023 15:14)
- Самое разумное в этой ситуации. Замена компилятора на рабочем проекте несёт риски. Лучше это делать в начале цикла разработки, когда отладка предстоит в любом случае. - SciFi(20.04.2023 14:28)
- Очевидно, код поплыл из-за ошибки в программе или из-за ошибки в
компиляторе (последнее маловероятно). - Nikolay_Po(20.04.2023 14:56)
- Безумству храбрых поём мы песню. Ну и первая версия: где-то не
хватает volatile. - SciFi(20.04.2023 13:32)
- меняется не в прерывании, причем в том же файле (в другой функции)
тоже меняется. кмк volatile не нужен - Andrey190(20.04.2023 13:48)
- Возможно компилятор посчитал, что это несколько разных переменных.
У них разные области видимости. - зaбыл(20.04.2023 13:51, )
- +1. Особенно, если объявили в заголовке без extern, а предупреждение в компиляторе выключено. - Nikolay_Po(20.04.2023 14:58)
- Без кода неинтересно. - SciFi(20.04.2023 13:50)
- Возможно компилятор посчитал, что это несколько разных переменных.
У них разные области видимости. - зaбыл(20.04.2023 13:51, )
- меняется не в прерывании, причем в том же файле (в другой функции)
тоже меняется. кмк volatile не нужен - Andrey190(20.04.2023 13:48)
- Я давно говорю, при разработке кода, сразу включайте все возможные
оптимизации, в том числе и LTO. Код будет качественнее, так как
увидите больше ошибок и предупреждений по делу. По крайней мере в
GCC (и AVR-GCC 12) так. Nikolay_Po(115 знак., 20.04.2023 14:54)