Модель памяти CoDeSys / ОВЕН ПЛК

[capzap]

что на этой картинке компилятор может смело выкинуть?

[Владимир Ситников]

что на этой картинке компилятор может смело выкинуть?

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

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

Целесообразно ли учить компилятор предвычислению такого цикла -- вопрос. С другой стороны, операцию "avg=ARDINST()" можно было бы и вынести из цикла (оптимизация loop invariant code motion часто даёт хороший прирост производительности).

Кстати, когда я говорю "компилятор", в эту же категорию попадает и CPU.
Смотрите: почти у каждого CPU есть store buffer (место, где хранятся команды на запись, которые уже обработаны в CPU, но ещё не записаны в память. Память обычно тормозная, поэтому store buffer имеет смысл). В итоге может оказаться, что одна команда записи ещё не закончилась, а другая команда уже началась. Если компилятор не будет генерировать специальные упорядочивающие команды, то CPU может переупорядочивать выполняемые инструкции (с точностью до модели памяти конкретного процессора).

Если бы все ассемблерные команды выполнялись ровно в том порядке как они написаны, то программы работали бы на порядок медленнее. Смысл переупорядочивания как раз в том, чтобы сделать такие правила, которые не выносят мозг программистам, и, в то же время, позволяют эффективно параллелить выполнение.