Arlleex

Да перейдите на другую версию компилятора. На предыдущей странице вы уже убедительное доказательство косяка IAR привели, когда к регистрам volatile полезли🙂 Значит в данном случае у IAR не такая агрессивная оптимизация. Что ж, бывает.

У меня IAR-а нету, но вот скрин из интернетов Видимо, у Вас какая-то старая совсем версия или что-то подобное.

ТС перепутал с const. Те да - по-умолчанию статические. У вас это вроде, называется, multi-file compilation. Но не знаю, запускается ли там полноценная LTO, и вообще есть ли она в IAR, т.к. это "фишка" GCC/CLang, т.к. они транслируют код сначала в IR (внутреннее представление), а уже потом его в общую сборную солянку bitimage, а уже потом в объектник, а уже потом в файл исполнения.

Я понимаю, о чем Вы пишете. Но повторюсь - Си предполагает, что на момент входа в main() состояние среды будет вполне детерминированным - т.е. глобальные статические переменные без явной инициализации или атрибутов для других инструментов (например, компоновщика) будут иметь значение 0. В приведенном ТС коде нет никаких сведений о явной инициализации или доп. атрибутах. Значит компилятор может смело полагаться, что при входе в main() в glb будет лежать 0. Хоть там три километра кода было до вызова main().

И у меня Си.

В стандарте так написано, потому что. Для примера, из C11 Это требование обязан соблюдать компилятор при генерации кода. А значит, может смело на это полагаться. Так у Вас Си или C++?

Я же вроде написал, что у меня при включенной LTO удаляется. При выключенной - нет.

Выше пост дополнил. Не выкинул. P.S. Более того, если в случае, когда код полностью выкидывался, переменную glb объявить с атрибутом размещения в неинициализируемой области, оптимизатор так же не выкинет код (потому что в этом случае он уже действительно не может полагаться на инициализацию 0 при входе в main()) uint8_t glb __attribute__((section(".bss.uninitSection"), used));

Работы с портами конкретно где? Перед циклом в main() или в функции foo()? При добавлении glb = GPIOA->IDR перед вызовом tst() в цикле main() код уже, конечно же, не выкинулся.

Это проблемы того, кто это пишет. Компилятор должен соответствовать правилам языка, а они вполне конкретны. Си ничего не знает ни об ISR, ни о задачах ОС, вызванных до main(). Поэтому может смело полагаться (если нет других ограничивающих факторов) на то, что в этой переменной будет именно 0, а не что-то другое, и тут же выполнить оптимизацию - в данном случае, выкинув весь код. Какое мне дело до того, что у ТС еще в проекте, если он привел вполне самодостаточный кусок кода, который я смог вставить в свой проект и скомпилировать? Я вставил ровно то, что он привел, и определил функцию foo() в другом сишнике, в ее теле сделал доступ к volatile, чтобы функция не выкинулась. Результат я написал - после входа в main() получил пустой зацикленный код. И да - у меня в этом тестовом проекте тоже много файлов, и до main() тоже кое-чего вызывается.

Тест ровно тот что ТС указал в первом топике.

Ну так конечно не выкинет, так как присвоение glb требует порождения побочного эффекта - доступа к volatile-объекту. Вот теперь да, можно сказать, что ошибка есть.

Я так и сделал, разумеется. Выкинул. Повторюсь, это при LTO. Поэтому говорю, что при High balanced в IAR возможно подобное поведение, т.к. в pdf-ке описания, которое я смог нагуглить за наносекунды, написано, что в этом случае компилятор может анализировать содержимое памяти для осуществления оптимизаций. Вопрос одновременно и простой и сложный, чтобы ответить на него вот так, с пыру)) Компилятор не транслирует строчки Си-кода в ассемблер... На основе Си-кода строится аналитическое дерево для выявления поведенческой модели. И именно этот механизм позволяет осуществлять различные оптимизации, такие, которые здоровому человеку в голову не придут. И главное правило оптимизатора - не ломать побочные эффекты программы, если они имеют смысл. Поэтому да, отладка кода у меня не выше -O1 (почти всегда -O0), финальный релиз тестируется и отдается в продакшн только в -Obalanced + LTO. Потому что при повышенных агрессивных оптимизациях всплывает очень много скрытых багов, которые можно поймать и починить.

CLang на максимальной оптимизации и LTO просто выкинул весь код. И правильно сделал. main() - точка входа в Си-программу, поэтому на момент входа все глобальные переменные без инициализации равны 0. В описании IAR-овского компилятора написано, что при High balanced осуществляется анализ памяти. Может, так он и сделал?

Ну нет так нет. Может, я что-то упускаю, но почему он будет разным?

С токи зрения наблюдаемого поведения Си-программы она полностью корректна. По сути будете получать один и тот же результат. Подумайте: если бы при оптимизации компилятор все равно транслировал "в лоб" все написанное, на кой были бы нужны все эти хитрые уровни оптимизаций?

Вы уточните, где вы видите ошибку, просто так просматривать сотню строк листинга вряд ли кому-то интересно. А, вижу комментарии. Ничего криминального компилятор не вычудил, ошибок нет.

За свою практику так и не пришлось пользоваться F3. Только на отладке лампочкой поморгал и все - из того, что запомнилось - состояние флешки по-умолчанию (стертое) 0x0, если не путаю🙂

А да. Мы пользуемся ей, я с телефона писал, не сразу увидел, что это для другой САПР. Но суть та же. Дык она затемняет другие компоненты и выделяет цветным контуром нужные компоненты. Разве так не удобнее?

А надо ли?

Справедливости для, все-таки, 32) но это не отменяет причуд)

Попробуйте показать ей https://electronix.ru/forum/topic/150632-interactive-bom/ ИМХО, самая полезная из всех помогалок, которые я видел. А просто выводить 3D-модели в чертеж не хотите? Или весь смысл в этой красной маркировке, чтобы ОТК было удобно смотреть? Все ключи на своих местах, нет возможности что-то перепутать. Драфтсман, конечно, та еще "удобная" программа, но ключи на микросхемах лучше доверить автоматизации...

https://electronix.ru/forum/topic/188090-zapreschennye-slova/

Да, эпюры вполне похожи на те, что в книжке. Включал основной софт, который взаимодействует с железкой. Да смысла особо нет рассуждать, правильно или нет было на ПЛИС - как считали нужным, видимо, так и делали. Я поставлю на шину данных 5В двунаправленный буфер, все остальные сигналы тоже через буферы однонаправленные пропущу. Прикинусь той самой железкой - работать будет, уверен))

Вообще, насколько я понял из беглого ознакомления со стандартом LPT, полноценный хост умеет "знакомиться" с девайсом путем нехитрых рукопожатий. Но! Мне нужно подыграть старую железку всего лишь для одного компа, который еще на ДОСе работает)) Поэтому я взял лог. анализатор, включил комп, а затем нагорячую подключил LPT и выяснил, что компу вообще пофигу на то, чего там умеет девайс. В биос жестко прошит режим EPP и я по лог. анализатору вижу последовательную запись адресов и чтения данных. Т.е. там N циклов "запись адреса - чтение данных". Одна линия управления от хоста не используется, всегда в лог. 1, две линии управления от девайса тоже "молчуны" - в неких лог. состояниях без изменения. Все данные, формат, кто за кем идет и какие биты за что отвечают - в течение сегодняшнего дня полностью определил. Единственное, комп шлет сигналы стробов весьма короткими - 0.5мкс, но еще заложен некий аппаратный flow control в виде сигнала Busy (Wait) от слейва. В принципе, к STM-ке через буфер все подцепляю и формирую нужные диаграммы. В течение месяца-другого, когда дойдут руки сделать прототип железяки, отпишусь о результатах (если не забуду). P.S. В подопытной железяке LPT-порт подключен к ПЛИСе.