Так приведите си-исходник, который будет компилироваться в такой код (который будет 64-битными словами и т.п.).
Я привёл не 2 совершенно разные программы, а взял результат компиляции одной программы и его оптимизировал на асме.
Я вообще-то говорю не об неэффективности компилятора, а показываю что он неидеален, и что код ТС-а скорей всего также возможно вручную оптимизировать лучше компилятора.
"Весьма неплохо" - это на взгляд тех, кто не хочет напрягать свой мозг и изучать ассемблер. Когда освоите ассемблер в достаточной степени, увидите сколько там возможностей для улучшений.
Потому что всё-таки люди обычно умнее компиляторов, иначе не люди писали бы компиляторы, а компиляторы - программировали голову. Ну это конечно касается только тех, кто эту самую голову использует по назначению.
Конечно и ковыряние и оптимизация на уровне алгоритма - тоже необходима, нужно действовать в комплексе.
Вот, для примера как-то у меня была задача - написал я функцию:
Скомпилилась она (максимальная оптимизация по скорости или балансная) в:
Скажете - "весьма неплохо"? А по мне - как-то не очень. И я, зная что (cnt == 0 || cnt > 4) и что входные данные (*src) - 14-битные (0...0x3FFF) и выровнены на 32бита, оптимизировал её так:
Как видно - разница очень даже заметная.
for (uint8_t i = 0; i < 10; i++) {...}
10 - по дефолту тип int, i - uint8_t (меньшего размера). Соответственно один операнд (меньшего размера) будет приведён к типу другого (большего размера и другой разрядности).
См. описание языка си, раздел правил приведения типов операндов внутри выражений.
Значит - данный компилятор в данном конкретном случае (с данными ключами) данный конкретный пример уже оптимизирует, приводя сразу типы операндов.
Вот что сказал IAR_7.80.4 for ARM (оптимизация - LOW):
Команда UXTB - это как раз и есть команда беззнакового расширения. Без которой можно обойтись, применив uint i.
Как справедливо заметил VladislavS приведения типа чаще можно увидеть при передаче аргументов функций не основной разрядности (разрядность != разрядности регистров CPU). Возьмите любой код, насыщенный всякими uint8_t/uint16_t в аргументах и локальных переменных функций, скомпилируйте его на 32-битной архитектуре, и увидите кучу UXTB/UXTH/SXTB/SXTH. Например этим сильно грешат исходники uCOS-II - всяких INT8U/INT16U в аргументах там полно.
То же самое касается и других архитектур (STM8 - в том числе), когда передаются аргументы в функцию или используются как локальные, переменные не основной разрядности. В STM8 предпочтительно использовать 8бит, если не лезет - 16бит, и только потом уже - 32бита.
Не только по стекам процессов, но и стек прерываний следует проверить. Как видно из содержимого регистров - Вы используете раздельные стеки для MSP и PSP. Его кстати ОС думаю не контролирует.
PS: В инфу, выдаваемую Вашим обработчиком HF, советую добавить инфу о состоянии PSP и MSP и содержимое верхушки активного стека.
PPS: В первую очередь я бы также советовал добиться стабильного проявления бага, а не раз в час. Для этого можно попробовать: включить оптимизацию по максимуму, или поменять ещё установки; поменять частоту CPU (при возможности); добавить дополнительные задачи, со случайной вычислительной загрузкой, ... Когда добьётесь стабильного проявления бага, это состояние стоит зафиксировать и в нём будет уже легче искать баг.
А всё-таки - ответьте на последний вопрос из https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=149961&do=findComment&comment=1598511
Ведь Ваш fault имеет PC=0x080D6626, а там portSET_INTERRUPT_MASK_FROM_ISR()
Или просто протрассируйте внутрь по шагам, по ассемблерному коду.
