Перейти к содержанию
    

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

 

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

    SCB_DEMCR |= 0x01000000;
    DWT_CONTROL|= 1; // enable the counter
    DWT_CYCCNT  = 0;

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

и не понятно какой кусок кода выполнился.

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

#include <intrinsics.h>

__no_operation();

или

__NOP();

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Менять местами - посмотрите pragma inline

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

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

Дело в том что я там всем почти функциям наставил static+ inline, что бы компилятор выворачивал их.

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

#include <intrinsics.h>

__no_operation();

или

__NOP();

Это тоже самое что asm("nop"); ?

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дело в том что я там всем почти функциям наставил static+ inline, что бы компилятор выворачивал их.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

1) А вот не надо лепить UB.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Такое ощущение, что помешались на оптимизации, и теперь пожинаете грабли в отладке.

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

 

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Если Вы создаете проект на ASM, в очень-очень жестком реалтайме, на сотню мегагерц тактовой, то

считать такты - дело благородное.

Если же проеект на С, а то и С++, то это, IMHO, тупик.

Если приходится "ужимать" время на выполнение процедур - надо брать более мощный процессор.

Или использовать специализированные средства (SW-HW), которые будут считать все "накладные расходы" вместо Вас.

-----

В редчайших случаях, когда мне необходимо просчитать (!) время работы какой-либо процедуры,

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

меряется осцилографом или даже лог. анализатором.

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если приходится "ужимать" время на выполнение процедур - надо брать более мощный процессор.

Да на си, но теоретически запас, в 2 раза должен был остаться, а он хоп и исчез вот и приходится искать, что же все время сьело.

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

 

Или использовать специализированные средства (SW-HW), которые будут считать все "накладные расходы" вместо Вас.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Увы решаю задачу ЦОС, надо оценить сколько тактов остается на запас, да и проанализировать за сколько тактов выполняются фильтры.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...