-
- Оптимизация - та ещё "штучка". Буду пристально её изучать, как в EW
для MSP430. 2kon(91 знак., 28.05.2022 22:03)
- Код, который не работает при включенной оптимизации, не имеет права
на существование. В своих проектах ничего кроме максимальной
оптимизации по скорости не использую, даже при отладке. - VladislavS.(31.05.2022 05:31)
- Не знаю, не знаю. Та же кроссплатформенная FatFs не проста и
оптимизатор IAR с ней не справляется. 2kon(82 знак., 31.05.2022 10:05 - 10:08)
- вполне себе справляется, глюков не замечал, оптимизация балансед - 0men(31.05.2022 15:08)
- Оптимизация High->Balanced, FatFs R0.13a и предыдущие все ок. Oman(120 знак., 31.05.2022 13:29)
- у меня R0.14b, ЯР 8.30.2, кстати, фатфс постоянно обновляю - 0men(31.05.2022 15:11)
- Пока остаюсь на стабильной 0.11a, несколько лет использования ошибок не выявило. 2kon(173 знак., 01.06.2022 08:12)
- у меня R0.14b, ЯР 8.30.2, кстати, фатфс постоянно обновляю - 0men(31.05.2022 15:11)
- Дьявол в деталях. Например, есть оптимизация, использующая правило
"strict aliasing". У компиляторов есть ключик, который отключает
только эту оптимизацию, потому что существует много готового кода,
нарушающего правило "strict aliasing". Формально это ошибочный код,
но что есть, то есть. В общем, если искать виноватых, там может
выясниться много интересного, и расследование может вывести на
самых неожиданных людей. - SciFi(31.05.2022 10:07)
- Нет охоты ковыряться в исходниках библиотеки и выяснять почему
авторы оптимизаторов не справились со сборкой. 2kon(126 знак., 31.05.2022 10:12)
- Просто интересно, что значит "не справились со сборкой"? Компилятор
падает и не может собрать код? - SciFi(31.05.2022 10:13)
- Библиотека работает некорректно. С FatFs это сразу обнаруживается
при использовании файловых функций. - 2kon(31.05.2022 10:15)
- Ну понятно. Скорее всего ошибки в коде, это бывает на порядки чаще,
чем глюки в компиляторе. Но если понижение уровня оптимизации
решает проблему, это тоже вполне годный путь. - SciFi(31.05.2022 10:17)
- А мне очень понятно, в своё время наелся "оптимизации" от Keil для
51. 2kon(115 знак., 31.05.2022 10:27)
- На самом деле критику такого рода не без основания направляют в
сторону творцов стандарта языка Си. Дескать, они закладывают туда
вот такие мины, как обычно, с благими намерениями (чтобы компилятор
имел возможность делать более быстрый код), но в результате
возникает множество неочевидных побочных эффектов. Это жизнь... - SciFi(31.05.2022 10:27)
- Даже в мыслях не было критиковать, мне надо чтобы библиотека
работала годами без проблем в устройстве. 2kon(90 знак., 31.05.2022 10:33)
- 👍 - SciFi(31.05.2022 10:35)
- Даже в мыслях не было критиковать, мне надо чтобы библиотека
работала годами без проблем в устройстве. 2kon(90 знак., 31.05.2022 10:33)
- На самом деле критику такого рода не без основания направляют в
сторону творцов стандарта языка Си. Дескать, они закладывают туда
вот такие мины, как обычно, с благими намерениями (чтобы компилятор
имел возможность делать более быстрый код), но в результате
возникает множество неочевидных побочных эффектов. Это жизнь... - SciFi(31.05.2022 10:27)
- Не раз бывало, что простое понижение уровня только маскировало проблему моего кода и при дописывании безобидного кода в другое место вылезали глюки уже на пониженной оптимизации. Хотя может я мало с чужим кодом работал. - Andreas(31.05.2022 10:26)
- А мне очень понятно, в своё время наелся "оптимизации" от Keil для
51. 2kon(115 знак., 31.05.2022 10:27)
- Ну понятно. Скорее всего ошибки в коде, это бывает на порядки чаще,
чем глюки в компиляторе. Но если понижение уровня оптимизации
решает проблему, это тоже вполне годный путь. - SciFi(31.05.2022 10:17)
- Библиотека работает некорректно. С FatFs это сразу обнаруживается
при использовании файловых функций. - 2kon(31.05.2022 10:15)
- Просто интересно, что значит "не справились со сборкой"? Компилятор
падает и не может собрать код? - SciFi(31.05.2022 10:13)
- Нет охоты ковыряться в исходниках библиотеки и выяснять почему
авторы оптимизаторов не справились со сборкой. 2kon(126 знак., 31.05.2022 10:12)
- Любая крайность не является мудрой позицией. Да, максимальная
оптимизация может помочь выявить глюки, которые могут вылезти в
другом месте и без оптимизации. В то же время часто имеет право на
жизнь подход "работает — и ладно", ибо перфекционизм сам по себе
есть нездоровая фигня. Здравый смысл и разумный баланс рулит. - SciFi(31.05.2022 08:03)
- Если речь идёт о БИБЛИОТЕКЕ, то моя крайность заключается в том,
что код должен корректно работать с разными компиляторами (IAR, GCC
и ARMClang в случае кортексов) при любом уровне оптимизации. - VladislavS.(31.05.2022 14:40)
- Боюсь, ваши призывы не по адресу. Присутствуют ли здесь авторы
БИБЛИОТЕК? Согласятся ли они с тем, что они что-то "должны"? Едва
ли по обоим пунктам. - SciFi(31.05.2022 14:50)
- Ну, нет так нет. Называем вещи своими именами и проходим мимо. - VladislavS.(31.05.2022 19:23)
- Ну никто не запрещает отсылать им патчи для исправления всякого. - LightElf(31.05.2022 15:27)
- Боюсь, ваши призывы не по адресу. Присутствуют ли здесь авторы
БИБЛИОТЕК? Согласятся ли они с тем, что они что-то "должны"? Едва
ли по обоим пунктам. - SciFi(31.05.2022 14:50)
- Если речь идёт о БИБЛИОТЕКЕ, то моя крайность заключается в том,
что код должен корректно работать с разными компиляторами (IAR, GCC
и ARMClang в случае кортексов) при любом уровне оптимизации. - VladislavS.(31.05.2022 14:40)
- Согласен, что если код не работает при полной оптимизации, то нужно искать косяк в коде. Но при полной оптимизации отлаживаться совершенно невозможно. Компилятор так всё запутывает, что потом брекпойнты не там где надо ставятся, значения переменных не отображает или неправильно отображает. - Ale3000(31.05.2022 07:59)
- Не знаю, не знаю. Та же кроссплатформенная FatFs не проста и
оптимизатор IAR с ней не справляется. 2kon(82 знак., 31.05.2022 10:05 - 10:08)
- С IAR for MSP430 был такой прикол при оптимизации: если main () в
самый конец исходника засандалить (типа опустить его ;) при
написании кода), то периодически (после компиляции проекта)
всплывала ошибка при исполнении кода в камне (у меня был
MSP430F149), диагностируемая только при отладке. Сразу и не
обнаружишь такую чу-чу. А если в самое начало, то всё норм.
откатывалось. Последние версии не отслеживал на этой платформе, но
думаю локализовали/исправили. - SERGHIO(30.05.2022 23:29)
- Глюки, пропадающие при перетасовке исходника, скорее указывают на
косяк в исходнике, чем в компиляторе. Там бывают довольно тонкие
эффекты. - SciFi(30.05.2022 23:38)
- Да не должно быть такового априори. Размещение main(void) в теле
исходника не регламентируется, но вот такое его перемещение в
режиме оптимизации пронаблюдалось. И разница откомпилированного
кода в том и ином случае была выявлена. Сначала на уровне
элементарной бинарной проверки в разнице результирущих файлов. А
потом и на уровне asm. - SERGHIO(31.05.2022 02:38)
- Легко, мой хороший. Кроме компиляции есть ещё и линковка, которая
даст разный результат. В правильном коде эти разные сборки должны
быть рабочими. Возможно, с другой времянкой, но логически рабочими.
Глюки в компиляторах, безусловно, были, есть и будут, но не на
такой банальщине. - VladislavS.(31.05.2022 05:46)
- ;) Замечательно! Но! Всё отлинковалось верно (в плане КОРРЕКТНОСТИ
исполнительного кода в реально работающем изделии). Никаких глюков!
НИКАКИХ! Но, в случае, когда main() размещался в начале исходника!
Так и было, естественно, оставлено в итоге. В случае его (main())
отправки в конец исходного текста проявился глюк при исполнении
кода. Ещё раз: Так не должно отрабатываться в любом компиляторе! Я
был сам в шоке от такой..."случайности". И ещё раз напомню, при
включении SERGHIO(565 знак., 31.05.2022 13:37 - 14:33)
- Симптомы, которые вы перечислили, не позволяют сделать однозначный вывод, что глюк в компиляторе, а не в исходнике. Более того, накопленный опыт говорит, что гораздо вероятнее, что глюк в исходнике. С другой стороны, поезд ушёл, как я понял. Изменит ли что-либо назначение виновных? - SciFi(31.05.2022 13:39)
- ;) Замечательно! Но! Всё отлинковалось верно (в плане КОРРЕКТНОСТИ
исполнительного кода в реально работающем изделии). Никаких глюков!
НИКАКИХ! Но, в случае, когда main() размещался в начале исходника!
Так и было, естественно, оставлено в итоге. В случае его (main())
отправки в конец исходного текста проявился глюк при исполнении
кода. Ещё раз: Так не должно отрабатываться в любом компиляторе! Я
был сам в шоке от такой..."случайности". И ещё раз напомню, при
включении SERGHIO(565 знак., 31.05.2022 13:37 - 14:33)
- Легко, мой хороший. Кроме компиляции есть ещё и линковка, которая
даст разный результат. В правильном коде эти разные сборки должны
быть рабочими. Возможно, с другой времянкой, но логически рабочими.
Глюки в компиляторах, безусловно, были, есть и будут, но не на
такой банальщине. - VladislavS.(31.05.2022 05:46)
- Да не должно быть такового априори. Размещение main(void) в теле
исходника не регламентируется, но вот такое его перемещение в
режиме оптимизации пронаблюдалось. И разница откомпилированного
кода в том и ином случае была выявлена. Сначала на уровне
элементарной бинарной проверки в разнице результирущих файлов. А
потом и на уровне asm. - SERGHIO(31.05.2022 02:38)
- Глюки, пропадающие при перетасовке исходника, скорее указывают на
косяк в исходнике, чем в компиляторе. Там бывают довольно тонкие
эффекты. - SciFi(30.05.2022 23:38)
- Код, который не работает при включенной оптимизации, не имеет права
на существование. В своих проектах ничего кроме максимальной
оптимизации по скорости не использую, даже при отладке. - VladislavS.(31.05.2022 05:31)
- Оптимизация - та ещё "штучка". Буду пристально её изучать, как в EW
для MSP430. 2kon(91 знак., 28.05.2022 22:03)