Есть проект. в нем один файл должен быть только с оптимизацией -О0, а другой только с оптимизацией -Ohs. Иначе прога не будет правильно работать. Как во время компиляции проверить, что к этим файлам применён нужный уровень компиляции?

есть проверки типа
Хотелось бы что-то подобное. если уровень оптимизации не тот, то выдать еррор и завершить компиляцию/сборку.

Задайте принудительно для фрагмента:
#pragma push
#pragma O0
...
#pragma pop

Это не очень хороший проект!
При желании всегда можно избавиться от такого поведения.
Могу помочь.

?

Спасибо, то что нужно!!! Только у меня в компиляторе так
#pragma optimize=none

А что в нём не хорошего? Для таких случаев придумали #pragma optimize, а не предлагают помощь в избавлении от такого поведения

Если поведение программы зависит от уровня оптимизации, значит программа написана неверно. Стоит решать проблему а не следствие.

Эти опции придумали, не для того, чтобы проект работал или не работал, а для оптимизации по памяти.
В некоторый задачах важна скорость, а памяти свободной много. В других задачах каждый байт на счету.

Есть место в программе, например обработчик прерывания.... без оптимизации один си-оператор есть 6 асм команд. без оптимизации почти 90% времени уходит на обработчик. прога не работает. с макс ур оптимизации по скорости этого обработчика си-оператор есть 4, а то и 2 асм команды. в итоге в прерывании 40-50% времени. прога работает без сбоев.

а то место, где optimize=none.... там используются дефайны регитров, библиотечные. можно канечно свои определить, обставить всё валатайлами.... в итоге асм получится 1в1 как с optimize=none. смысыл перелопачиать библиотечные дефайны и тратить время на "красивый код", если optimize=none решает проблему?

Проблема в том, что оптимизатор оптимизирует этот код. Отключить оптимизацию можно волотайлами или optimize=none. кому что милее

Еще в деле увеличения производительности очень помогает выравнивание данных. Все 8-ми и 16-ти битные данные нужно заменить на 32-битные.
Массивы копировать или очищать сразу по 32 бита. Ну и главный козырь - попробовать перенести рутину на аппаратные блоки (DMA, таймеры, SPI и т.п.)
Как правило, чем жирнее обработчик (а это на самом деле должно насторожить), тем больше возможностей для оптимизации. Крошечный обработчик можно
и ручками (читай на asm) написать. Вообще архитектура проекта должна быть заточена под эти "критические" обработчики.
Если не считать выключенную оптимизацию, то разница между результатом для разных уровней оптимизации (при оптимальном на C-уровне коде) не значительна. Точне не 2 раза.

В данном случае отсутствие volatile у регистров преступление. Нужно править библиотеку. Насчет 1в1 не полностью верно, ведь кроме доступа к регистрам есть и другой код. Выключение оптимизации не решение, т.к. при обращении из разных кусков программы (в том числе и с включенной оптимизацией) поведение будет разным. Может, вместо "optimize=none"/"optimize=yes" при каждом обращении к переменной в критичном к скорости модуле легче в одном месте написать volatile и иметь рабочий код при любом уровне оптимизации?

Естественно. Но задач столько впихнули в этот проект и попытались его седать не на intel i7, а на проце попроще. экономика должна быть экономной. аппаратные блоки и без этого нагружены по максимуму.

А что за процессор Вы используете, если не секрет?

Вы рано или поздно с таким не системным подходом упрётесь в стену. Тем более, что проект с ваших слов - большой.
Вы ведь себя программистом называете, не так-ли?
А выёживаетесь как студент с несчастливым билетом на экзамене. Простите за прямоту.
В конечном итоге вольному - воля, но я не хотел бы быть в числе тех кому достанется радость работать с вашим конечным продуктом.

Присоединяюсь к вопросу. Мне тоже очень интересно, производитель какого контроллера не озаботился словом volatile в описании регистров.

stm32 cm3. про библы от производителя речи не было.

2demiurg_spb, вы со своим подходом смотрите не упритесь.

Прочему прогеры такой народ? Если кто-то что-то делает не по их евангелию, то он не прав. Да ещё и не скупятся потролить. Почему именно ВАШ системный подход тру? Почему вы решаете, что иссус правильный бог. Почему не ЛММ? Когда такие ковбои-идеалисты сталкиваются с любым кодом, они сразу же начинают истерить и пытаться переписать всё с нуля по своим лекалам.

Вы же не знаете и толики того ТЗ, что у меня. Не имеете представления об объеме, задачах, капризах заказчика, какие либы можно юзать, а какие нет.

Я абстрагировался от всего тз и спросил конкретно про оптимизацию. Я не просил помощи в системном подходе. Проблема решена. Обязательно найдется идеолог который попытается "залезть в душу" и гавном кинуть.


Ну ваша вера. Уважаю. Перевербовывать вас не собираюсь. Оскорблять "выёжывающимся студентом" и назвать ваш продукт гавном не намерен. Моя вера иная. Есть места в программе, где каждый тик на счету, жёсткий реал тайм. Грубо говоря тиком больше, тиком меньше - в итоге фронт импульса не в том месте. Улетели....

Полностью согласен. Успех программиста МК, я считаю, заключается в многократном использовании кода. Когда одно отлаженное решение можно использовать в разных проектах (и даже на разных архитектурах). Скорость и качество разработки возрастает, функциональность тоже, т.к. часть отведенного на разработку времени отсвобождается за счет применения готовых решений, и можно уделить время доп. плюшкам. Поэтому я в лучших традициях "русские долго запрягают, зато потом быстро едут", очень скурпулезно делаю библиотеки. В рамках большого проекта остутствие библиотек или их кривизна смерти подобна.

На форуме ТС реально помогает и неплохо ориентируется в вопосах RTOS, поэтому ярлык "студент" тут не подходит. Если есть такая возможность, то нужно посадить за выпрямление библиотек "настоящего студента", четко сформулировав для него задачу, - тот и полезное дело сделает и опыту поднаберется. Реальные разработчики должны думать над архитектурой)

То, что в рамках STM32 на Cortex-M4 можно сделать очень сложные проекты полностью согласен. Хорошо, когда функционал известен заранее, хуже - когда
добавляется в процессе разработки. Тогда и вылезают всякие "костыльные решения".

Да, и не забываем про сопровождаемость кода. Сами откроете через год или другой разработкик возьмется за поддержку для галочки написанного приложения - времени и нервов будет потеряно немало.

Да, ненавижу костыльные решения. Но в это случае это не костыль. Это решение проблемы. Ещё раз повторю - вы не знаете ни тз, ни проект.... вообще ни чего не знаете и не вам решать про костыли и системные подходы.

Всем спасибо за помощь/диалог. Тема закрыта.