Здравствуйте, kov_serg, Вы писали:

_>
_>В некоторых DSP-никах после выполнения операции еще надо пару нопов добавлять иначе не работает. Или еще несколько команд после ret могут исполнят

То есть, старая шутка про ассемблер

jmp X
jmp X  ; если вдруг первый jmp не сработает

для некоторых — совсем не шутка?

Здравствуйте, kov_serg, Вы писали:

К>>Там нет какой-нибудь инструкции типа halt, которая повесила бы процессор в ожидание прерываний?
_>

_>di
_>hlt
_>

Хм, просили _в ожидание_ прерываний...

_>В некоторых DSP-никах после выполнения операции еще надо пару нопов добавлять иначе не работает. Или еще несколько команд после ret могут исполнят

Delay slots?

Здравствуйте, flаt, Вы писали:

F>

F>jmp X
F>jmp X  ; если вдруг первый jmp не сработает 
F>

F>для некоторых — совсем не шутка?
Да особенно если микроконтроллер работает в сильных радиационных полях. Сбои довольно частое явление.

Здравствуйте, Кодт, Вы писали:

К>А какой смысл микроконтроллеру полностью нагрузить ядро?

Это проще всего. Подключен он к компьютеру, потребляет доли ватта, не нагревается ни на сколько.

К>Там нет какой-нибудь инструкции типа halt, которая повесила бы процессор в ожидание прерываний?

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

Здравствуйте, kov_serg, Вы писали:

F>>jmp X ; если вдруг первый jmp не сработает
F>>для некоторых — совсем не шутка?
_>Да особенно если микроконтроллер работает в сильных радиационных полях. Сбои довольно частое явление.

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

Здравствуйте, graniar, Вы писали:

G>Ну так там тогда много где переглючить может, sub вместо add и тп. Такое только избыточностью процессорной архитектуры можно пытаться решать, а никак не задваиванием инструкций.
Вообще дублированием подсистем решают.

A>Вопрос про С был — там имхо это не так.

http://port70.net/~nsz/c/c11/n1570.html#6.8.5p6 почти так

Здравствуйте, σ, Вы писали:

σ>http://port70.net/~nsz/c/c11/n1570.html#6.8.5p6 почти так

Почти так, но не совсем.

while(true) и for(,,) имхо являются циклами, управляющее выражение которых является константой и они не должны съедаться оптимизатором.

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

Здравствуйте, graniar, Вы писали:

G>Ну так там тогда много где переглючить может, sub вместо add и тп. Такое только избыточностью процессорной архитектуры можно пытаться решать, а никак не задваиванием инструкций.

SystemZ ещё со времён IBM 370 решает проблемы именно задваиванием инструкций (аппаратно — в коде один экземпляр, а выполняется два раза подряд), тотальным сквозным контролем целостности данных — чётность плюс коды Хоффманна, и RAIM (как RAID, но на оперативной памяти) на памяти. Я думаю, их авторитету тут можно доверять.

Здравствуйте, kov_serg, Вы писали:

F>>

F>>jmp X
F>>jmp X  ; если вдруг первый jmp не сработает 
F>>

F>>для некоторых — совсем не шутка?
_>Да особенно если микроконтроллер работает в сильных радиационных полях. Сбои довольно частое явление.

Там или несколько параллельно работающих блоков, или аппаратное выполнение дважды одной и той же одиночной инструкции (как ни странно, вполне себе не "космическая" SystemZ).

А вот где такое я реально видел — в драйвере HPET (сейчас что-то не нашёл). Один регистр ставится дважды подряд. Но это специфика данного устройства, которое сделали внутри максимально асинхронным с одновременно двумя тактовыми частотами.

Здравствуйте, kov_serg, Вы писали:

_>Очевидно же для отладки или для ожидании watchdog-а.

... или если вся работа выполняется в обработчиках прерываний.

Здравствуйте, andyp, Вы писали:

A>... или если вся работа выполняется в обработчиках прерываний.

Для этого существуют разные уровни засыпаний.

Здравствуйте, cppguard, Вы писали:

C>Для этого существуют разные уровни засыпаний.

... которые не имеет смысла использовать в куче сценариев.

Здравствуйте, kov_serg, Вы писали:

A>>А на каком, пардон, основании? Бесконечный цикл — это же не if (false). Совсем охренели эти оптимизаторы.
_>До многих это доходит медленно. Современный C++ полон таких подстав. И что самое интересно многие с пеной у рта яростно защищают такое положение дел тыкая носом в стандарт. Похоже там есть яркие представители нетрадиционной ориентации логики и именно они имеют решающий голос в таких вопросах.

Я читал статью под названием C must die (или как-то так). Несмотря на провокационное название, статья была исключительно по делу и как раз про оптимизаторов, которые отобрали контроль у низкоуровневых разработчиков.

Ссылку сейчас не найду, но может, кто-то помнит.

Здравствуйте, reversecode, Вы писали:

R>упустили самое важное
R>отсылки к стандарту
R>которые там по несколько раз приводили разнцыми цитатами

Да там не понятно, то ли это С++, то ли это C...

Здравствуйте, Кодт, Вы писали:

К>Согласно стандарту, вечный цикл без побочных эффектов — это неопределённое поведение.
Почему именно неопределённое поведение, а не ошибка компиляции?

Здравствуйте, Alekzander, Вы писали:

A>Я читал статью под названием C must die (или как-то так). Несмотря на провокационное название, статья была исключительно по делу и как раз про оптимизаторов, которые отобрали контроль у низкоуровневых разработчиков.
A>Ссылку сейчас не найду, но может, кто-то помнит.

оно?
https://veresov.pro/cmustdie/

Ну идея явно провокационная. Особенно сейчас. Лет 15 назад я бы встал на сторону "людей", но сейчас только на стороне "машин". Человек не в состоянии уследить за всеми граблями. Если человек не может правильно проверить переполнение так нефиг писать на С, пиши на Rust.

Здравствуйте, sergii.p, Вы писали:

SP>https://veresov.pro/cmustdie/

SP>Если человек не может правильно проверить переполнение так нефиг писать на С
Дело в что помимо синтаксиса языка, человеку надо держать в уме как правильно по этикету стандарту объяснить компилятору тривиальные вещи.
Вообще люди похоже стали забывать для чего изначально компилятор был нужен и мы наблюдаем развитие карго-культа оптимизаций ради оптимизаций.

Резюмируя:

Пустой цикл в языке C не должен оптимизироваться. Пустой цикл в языке С++ может оптимизироваться.

Моё предположение было основано на том, что я в godbolt использовал C++, не подумав о том, что в этом моменте семантика у C и C++ отличается. Если в godbolt выбрать С, то пустой цикл не убирается.

Цитаты из стандартов:

C17 6.8.5: An iteration statement may be assumed by the implementation to terminate if its controlling
expression is not a constant expression

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

C++20 6.9.2.2: The implementation may assume that any thread will eventually do one of the following: terminate.

This is intended to allow compiler transformations such as removal of empty loops, even when
termination cannot be proven

Т.е. тут всё явно написано, пустые циклы надо убирать.

Здравствуйте, B0FEE664, Вы писали:

К>>Согласно стандарту, вечный цикл без побочных эффектов — это неопределённое поведение.
BFE>Почему именно неопределённое поведение, а не ошибка компиляции?

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