caxapa.ru :: Оптимизация - та ещё "штучка". Буду пристально её изучать, как в EW для MSP430.

2kon (28.05.2022 22:03, просмотров: 2671) ответил Oman на у меня на макс оптимизации без траблов, на объектах пашет.

Оптимизация - та ещё "штучка". Буду пристально её изучать, как в EW для MSP430.

Возможно и вовсе без неё обойдусь во избежание проблем при сборке заимствованных библиотек.

Ответить

- Код, который не работает при включенной оптимизации, не имеет права на существование. В своих проектах ничего кроме максимальной оптимизации по скорости не использую, даже при отладке. - VladislavS.(31.05.2022 05:31)
- С 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)
        
        Грешу не на исходник, а на режим назначенной оптимизации. В силу ЧЁТКОЙ отработки результирующего кода уровень оптимизации (size) был оставлен! И ...ДА!;) Поезд успешно был отправлен. Никаких нареканий не поступало. Виновные получили... условный срок! ;) - SERGHIO(31.05.2022 14:26)

Средства и методы разработки