День добрый.

Столкнулся с проблемой оптимизации, при инкременте указателя когда 2 строчки подряд. Оптимизация макс. по скорости. IAR ARM 7.40.3. Мк STMF4


скрины ассемблера
без оптимизации

макс. оптимизация по скорости

макс. оптимизация по скорости + NOP


Вопрос, возможно ли сделать запись чтобы не оптимизировался инкремент указателя? NOP конечно не критичен, но костыль. Отключить оптимизацию только для ф-ции не рассматриваю, т.к. подобные записи оформил виде макросов и могут быть в разных участках кода

Кстати, безотносительно к тому, есть ли там volatile и в правильных ли местах, важно следующее:
У вас в программе есть прерывания и/или многопоточность (т.н. RTOS)? Потому что volatile только в этом случае имеет значение.

Эта строчка есть абсолютный говнокод. Рассуждать, как компилятор должен говнокод компилировать, можно бесконечно.
Но без потытки сбить оптимизацию квалификатором volatile, любые инкременты переменной по указателю должны безусловно выбрасываться, как бесполезные. Что и сделано.
С volatile оптимизация может быть порушена.
Напишите, что надо делать компилятору четко. Но начните с попытки объяснить СЕБЕ.

К данным. Читается справа налево. Указатель на волатайл переменную типа бла-бла.

*((*ppData_tx)++) = *((*ppData_rx)++);
Вообще это изменение одной переменной между двумя точками следования. Это в свою очередь UB. Поэтому компилятор прав, вы - нет. Пишите подобное с временной переменной. Это работает в отладке потому что там компилятор что видит, то и поёт. С нопом это работает по счастливой случайности, из-за особенностей оптимизации конкретным компилятором.

Сообщение отредактировал Kabdim - Oct 2 2015, 11:08

многопоточности нет (RTOS тоже), раньше код был с разделением взятия переменной и инкрементом указателя, работало с оптимизацией и без. решил записать всё в одну строчку, для компактности и чтобы сделать макрос. Нет проблемы записать по другому с доп. переменной и т.п., хотелось записать одной строчкой.

По поводу говнокода, каждому своё, тогда и DSP Lib от ARM тоже говнокод, там такие записи встречаются.
Найти ошибку будет сложнее, но эта запись как результат сворачивая из нескольких записей на уже отлаженном коде.



переменная тут не меняется, она копируется из _rx в _tx, а адреса буферов меняются

переменные нигде не меняются, меняется (инкрементируется) только указатель на входные буфера

Прошу прощения, проглядел.

Тогда зачем там volatile? Взаимодействие с аппаратными регистрами?

Чтобы сделать вывод, что это компилятор виноват, в идеале хорошо бы попытаться получить минимальную программу (легко обозримую), в которой проблема по-прежнему проявляется. Потому что всё-таки гораздо чаще оказывается, что виноват автор кода, а не компилятор.

компилятор я нигде не обвинял, а только спрашивал, что не так, в расчёте, что укажут на ошибку или я смогу понять где она. С volatile или без результат одинаковый, предполагал, что он относится к указателю, а не к значению. Позже попробую другие вариации попроще.

А можно было бы. Изредка и он виноват. Я сталкивался не единожды.


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


А всё-таки, поясните, зачем там volatile? Если нет RTOS, прерываний и аппаратных регистров, то volatile ничего не изменит.

я правильно перевел с птичьего языка на норм.?



???

scifi, мне интересно, что вас задел этот volatile или слово жалоба? через volatile объявляю только приведение типов по указателю, в книжках читал про это. Прерывание есть, какая реальная программа без прерываний. Ещё на время отладки volatile объявляю float, чтобы watch отображался.

_Pasha, ну на птичий язык не совсем тянет, хотя запись с указателями перегружена для непосвящённых
По записи вроде всё верно, хотя не проверял, до понедельника не на чем. Но смысл не постоянно писать такими громоздкими записями, а завернуть их в макросы или для противников макросов в inline функции и использовать
это макрос один

это второй

но так получилось, в данной ф-ции, что подряд идущие 2 эти строчки оптимизируется и я вставил NOP между ними. Приводить большие куски кода не вижу смысла т.к. необходимо в любой конструкции работа этих макросов.

немного OFFTOP:
Другой случай где понадобился NOP, это для анализатора стека. При максимальной оптимизации по скорости (на других не пробовал) в switch вызывались различные ф-ции в зависимости значение case. Все вызовы ф-ций при этом подменялись с CALL на JMP (это на AVR) и анализатор выдавал предупреждение о косвенном вызове и не мог составить дерево вызовов. Причём ни прагмой, ни описанием в файле конфигурации, я так и не смог указать правильное дерево вызовов для данного случая. Но если в конце перед выходом из ф-ции (после switch) поставить NOP такой подмены не происходит и анализатор нормально работает.
Естественно, на работоспособность программы это не влияет, но анализатор хорошая штука чего б не использовать.

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


2. Ход мыслей понятен, но имхо такое, что нет смысла бояться локальных переменных даже в таком случае.
Т.е. в случае с макросом - обернуть его в do{}while(0) и создавать столько локальных перем. сколько нужно.

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

так там вообще неправильный код сгенерировался.
пришлось исправить на

вот те на, CSE
но то sdcc. милость к падшим тсз нада проявлять