Инкремент указателя и оптимизация Опции

[Rash]

День добрый.

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

Код

static void _setup_resp_ready(uint8_t** ppData_rx, bool allow_addr, uint8_t** ppData_tx)
{
  if(allow_addr != false)
    *(*(volatile uint_setup_addr_t**)&(*ppData_tx))++ = setup_addr;
  
  // !!! если NOP нет, то код будет оптимизирован
  __ASM("NOP");
    
   *((*ppData_tx)++) = *((*ppData_rx)++);
  
  return;
}

Прим. uint_setup_addr_t - задаётся тип, на данный момент uint16_t

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

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

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


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

[Rash]

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

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

Код

*(*(volatile uint_setup_addr_t**)&(*ppData_tx))++ = setup_addr;

это второй

Код

*((*ppData_tx)++)

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

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

[_Pasha]

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

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

Код

*ppData_tx = ptx;
*ppData_rx = prx;

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

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

Код

crc = (crc >> 1)^((crc & 1)? 0x8C:0);

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

Код

crc = ((crc & 1)? 0x8C:0) ^ (crc >> 1);

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