Добрый день подскажите как выключить оптимизацию для куска кода внутри функции ?

Дело в том что надо определить точное выполнение кода при максимальной оптимизации использую

и потом считываю DWT_CYCCNT, но проблема в том что при максимальной оптимизации, программа пролетает breakpoint, который я установил
и не понятно какой кусок кода выполнился.

Так вот как установить NOP, что бы при максимальной оптимизации он остался, и на него можно было повесить breakpoint ?

копните в направлении #pragma optimize

Да это я уже нашёл, но как я понял она только в функциям применяется, а если чтение DWT_CYCCNT запихать в функцию то фиг поймешь сколько он тактов на вход функцию будет тратить и будит ли вообще.

Да и я смотрю что компилятор любитель, местами менять операции. Это бы тоже хотелось избежать при чтении DWT_CYCCNT

Сколько тратит на вход в функцию это можно в ассемблере посмотреть. Менять местами - посмотрите pragma inline

Найти в дизассемблере нужную операцию и поставить точку останова там.


Компилятор не будет менять порядок операций с переменными volatile. Можете спать спокойно.

#include <intrinsics.h>
__no_operation();
или
__NOP();

Хорошо гляну, а оно разве не просто выворачивание функции?

Дело в том что я там всем почти функциям наставил static+ inline, что бы компилятор выворачивал их.
так вот после этого в дизассемблере, комментарии сишного когда начинают пропадать. Точнее они есть, но целиком кусок комментарий функции на си, а потом кусок ассемблерного когда, и там становиться логику сложновато понять.

Это тоже самое что asm("nop"); ?
Я думал при высокой оптимизации он их выкинет совсем, но сегодня вечером увидел что он их только передвинул.

Такое ощущение, что помешались на оптимизации, и теперь пожинаете грабли в отладке. Оптимизация ради оптимизации - зло. Более того, если прошивка отлажена и работает без оптимизации, то пусть так и остаётся. Да, при повышении уровня оптимизации могут вылезти новые ошибки, которые лучше бы исправить, но это уже производная второго порядка.

А после этого оптимизировать понадобилось, да вот в прошивке UB на UB и UB погоняет. А ловить их только огромной кровью, когда неизвестно в каком комите они появились. Не понимаю я людей которые в процессе разработки не тестируют работоспособность при максимальной оптимизации.

1) А вот не надо лепить UB.
2) Очевидно, ТС со столь высокими материями не заморачивается. Ему бы тупо научиться отлаживать хоть что-то.

Увы решаю задачу ЦОС, надо оценить сколько тактов остается на запас, да и проанализировать за сколько тактов выполняются фильтры. До написания фильтров на ассемблере ещё не дошел, но если понадобиться то приодеться. Но в принципе сишный код не плохо компилируется.

Если Вы создаете проект на ASM, в очень-очень жестком реалтайме, на сотню мегагерц тактовой, то
считать такты - дело благородное.
Если же проеект на С, а то и С++, то это, IMHO, тупик.
Если приходится "ужимать" время на выполнение процедур - надо брать более мощный процессор.
Или использовать специализированные средства (SW-HW), которые будут считать все "накладные расходы" вместо Вас.
-----
В редчайших случаях, когда мне необходимо просчитать (!) время работы какой-либо процедуры,
я использую или таймер, который "уже есть", или вывожу "рамочный" строб на вывод порта, который абсолютно точно
меряется осцилографом или даже лог. анализатором.

Да на си, но теоретически запас, в 2 раза должен был остаться, а он хоп и исчез вот и приходится искать, что же все время сьело.
А вывод стробом уже имеется, но больше в % на глаз дает информацию.


Это какие к примеру?

У вас нет коллег и общих библиотек?

А что простой способ: "выполнить этот фильтр N раз, измерить общее время (по таймеру) и поделить на N" - не помогает?