Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Среда
17 июля

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

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

1212099 Топик полностью

Oman (28.05.2022 17:32, просмотров: 401) ответил 2kon на Спасибо, интересно наблюдать за прикручиванием новых стандартов к C++.

9ка прям сильно шустрее стала компилировать

Ответить

- Неважно, не так много файлов собирается. 2kon(108 знак., 28.05.2022 20:10)
  - у меня на макс оптимизации без траблов, на объектах пашет. Oman(65 знак., 28.05.2022 21:27)
    - Оптимизация - та ещё "штучка". Буду пристально её изучать, как в 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)
        
        Дьявол в деталях. Например, есть оптимизация, использующая правило "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)
        
        Не раз бывало, что простое понижение уровня только маскировало проблему моего кода и при дописывании безобидного кода в другое место вылезали глюки уже на пониженной оптимизации. Хотя может я мало с чужим кодом работал. - Andreas(31.05.2022 10:26)
        
        Любая крайность не является мудрой позицией. Да, максимальная оптимизация может помочь выявить глюки, которые могут вылезти в другом месте и без оптимизации. В то же время часто имеет право на жизнь подход "работает — и ладно", ибо перфекционизм сам по себе есть нездоровая фигня. Здравый смысл и разумный баланс рулит. - 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)
        
        Согласен, что если код не работает при полной оптимизации, то нужно искать косяк в коде. Но при полной оптимизации отлаживаться совершенно невозможно. Компилятор так всё запутывает, что потом брекпойнты не там где надо ставятся, значения переменных не отображает или неправильно отображает. - Ale3000(31.05.2022 07:59)
        
        В таком случае хорошо помогает отладочный вывод из самой программы. Дёрнул выводом, как дошёл до места; вывел в UART сообщение, как достиг заданной величины и т.п. - Nikolay_Po(31.05.2022 08:07)
      - С 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)