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

В голову, конечно, сразу приходит for ( ; ; ) {} но clang с оптимизацией этот цикл тупо выкидывает.

Можно написать for (volatile unsigned unused; ; unused++) {} этот код не выкидывает, но мне не нравится, что он постоянно гоняет трафик между процессором и оперативной памятью, например это может мешать DMA-передачам.

Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?

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

while (true)

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

vsb>В голову, конечно, сразу приходит for ( ; ; ) {} но clang с оптимизацией этот цикл тупо выкидывает.

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

vsb>Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?

Нет.

Я бы вставил в цикл пустую ассемблерную вставку. Даже не из nop, а из пустой строки.

Компилятор не понимает этих вставок, но знает, что не понимает, и поэтому не выкидывает.

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

Н>while (true)

https://godbolt.org/z/5Gnsxh5cj

armv7-a clang, -Os

int main(void)
{
    while (true);
}

main:

Выкинул цикл.

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

Может потому что тело цикла пустое?
Виндовый цикл обработки сообщений именно так выглядит

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

Pzz>Я бы вставил в цикл пустую ассемблерную вставку. Даже не из nop, а из пустой строки.

Спасибо, так работает, конечно есть опасения, что "завтра" он может стать умней и выкинуть и такой цикл. Я так понимаю, asm это по определению implementation-defined. Ладно, будем надеяться, что хоть такой специальный случай оставят.

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

Н>Может потому что тело цикла пустое?

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

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

Попробуй два ссылающихся друг на друга goto

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

Pzz>>Я бы вставил в цикл пустую ассемблерную вставку. Даже не из nop, а из пустой строки.

vsb>Спасибо, так работает, конечно есть опасения, что "завтра" он может стать умней и выкинуть и такой цикл.

Нет, вряд ли. Ему для этого придется научиться понимать ассемблер, а зачем ему это надо?

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

Н>Попробуй два ссылающихся друг на друга goto

Такое

int main(void)
{
    a: goto b;
    b: goto a;
}

не работает, "оптимизирует".

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

vsb>>Спасибо, так работает, конечно есть опасения, что "завтра" он может стать умней и выкинуть и такой цикл.

Pzz>Нет, вряд ли. Ему для этого придется научиться понимать ассемблер, а зачем ему это надо?

РаздражатьУдивлять программистов, конечно, для чего же ещё может понадобиться "оптимизировать" пустые циклы (:

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

vsb>В голову, конечно, сразу приходит for ( ; ; ) {} но clang с оптимизацией этот цикл тупо выкидывает.

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

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

vsb>В голову, конечно, сразу приходит for ( ; ; ) {} но clang с оптимизацией этот цикл тупо выкидывает.
Просто выкиньте clang и используйте нормальный компилятор.

Пишется на ассемблере загрузчик, который после инициализации стека и другой фигни
вызывает setup() и потом loop() в бесконечном цикле. Посмотрите на arduino

void setup() {
  //
}
void loop() {
  
}

vsb>Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?
да, но для этого отключите е$@нутые оптимизации clang для файла boot.c

void _start() {
  SET_STACK();
  setup();
  for(;;) loop();
}

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

Pzz>>Нет, вряд ли. Ему для этого придется научиться понимать ассемблер, а зачем ему это надо?

vsb>РаздражатьУдивлять программистов, конечно, для чего же ещё может понадобиться "оптимизировать" пустые циклы (:

Они по дефолту оптимизируются. Чтобы они не оптимизировались, надо специально усилия предпринимать.

P.S. В инструкции к gcc, когда я ее читал последний раз, было написано, что gcc понимает пустой цикл, как такой специальный случай, и сознательно его не оптимизирует.

Похоже, это еще одно знание, утраченное цивилизацией — то ли в clang, то ли вообще...

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

Pzz>Похоже, это еще одно знание, утраченное цивилизацией — то ли в clang, то ли вообще...

Как и любое такое знание — из разряда умения постройки пирамид. Утратилось, потому что не нать

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

Pzz>>Похоже, это еще одно знание, утраченное цивилизацией — то ли в clang, то ли вообще...

Н>Как и любое такое знание — из разряда умения постройки пирамид. Утратилось, потому что не нать

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

А если теперь в нем это постепенно отмирает, нафиг он вообще нужен?

Просто раньше за ним живые люди стояли, типа Ричи и Томпсона, которые понимали, что они делают. А теперь коллективный разум в виде коммитета по стандартизации. А "коллективный" — это, считай, никакой.

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

vsb>Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?

Попробуй

loop : goto loop;

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

vsb>В голову, конечно, сразу приходит for ( ; ; ) {} но clang с оптимизацией этот цикл тупо выкидывает.

А на каком, пардон, основании? Бесконечный цикл — это же не if (false). Совсем охренели эти оптимизаторы.

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

Pzz>Просто раньше за ним живые люди стояли, типа Ричи и Томпсона, которые понимали, что они делают. А теперь коллективный разум в виде коммитета по стандартизации. А "коллективный" — это, считай, никакой.
Точно: — У семи нянек детё без глаза.

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

vsb>>Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?

PD>Попробуй

PD>loop : goto loop;

Выкидывает.

https://stackoverflow.com/questions/59925618/how-do-i-make-an-infinite-empty-loop-that-won-t-be-optimized-away

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

Pzz>>Просто раньше за ним живые люди стояли, типа Ричи и Томпсона, которые понимали, что они делают. А теперь коллективный разум в виде коммитета по стандартизации. А "коллективный" — это, считай, никакой.
_>Точно: — У семи нянек детё без глаза.

У семи нянек 14 сисек.

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

R>https://stackoverflow.com/questions/59925618/how-do-i-make-an-infinite-empty-loop-that-won-t-be-optimized-away

Спасибо, видел, но там толкового решения не нашёл, всё в итоге сводится к asm или нерабочие решения, была надежда, что что-то упустили на SO.

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

vsb>Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?

https://godbolt.org/z/qnWzvM6eo

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

Pzz>Здравствуйте, Нomunculus, Вы писали:

Pzz>>>Похоже, это еще одно знание, утраченное цивилизацией — то ли в clang, то ли вообще...

Н>>Как и любое такое знание — из разряда умения постройки пирамид. Утратилось, потому что не нать

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

Pzz>А если теперь в нем это постепенно отмирает, нафиг он вообще нужен?

Pzz>Просто раньше за ним живые люди стояли, типа Ричи и Томпсона, которые понимали, что они делают. А теперь коллективный разум в виде коммитета по стандартизации. А "коллективный" — это, считай, никакой.

Может просто пофиксить компилятор? Разве стандарт языка позволяет выкидывать пустые циклы?

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

vsb>>Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?

M>https://godbolt.org/z/qnWzvM6eo

Я так понял, разница в том, что у меня был C++, а в этом примере C. Это обусловлено разницей в стандартах или в clang для C прописано исключение?

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

Pzz>>Просто раньше за ним живые люди стояли, типа Ричи и Томпсона, которые понимали, что они делают. А теперь коллективный разум в виде коммитета по стандартизации. А "коллективный" — это, считай, никакой.

S>Может просто пофиксить компилятор? Разве стандарт языка позволяет выкидывать пустые циклы?

Ну если они без побочных эффектов, окромя того, что процессор делом занимают, почему нет?

Я вообще не удивлюсь, если в нонешнем стандарте нескончаемый цикл без побочных эффектов — это UB. Лень смотреть...

vsb>>>Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?
M>>https://godbolt.org/z/qnWzvM6eo
vsb>Я так понял, разница в том, что у меня был C++, а в этом примере C. Это обусловлено разницей в стандартах или в clang для C прописано исключение?

Так ты вроде и просил на С изначально.
Чем обусловлено
Я сам удивлен, но из всех компиляторов что я проверил только clang++ выкидывает такой цикл. Причем это только на транке, стабильные релизы не выкидывают.
ПС: хотя если еще проверить неармовые версии clang++, то начиная с 13-ой версии выкидывает цикл.

Почему компиляторы не следуют стандарту?

consteval функцию нельзя вызывать в run time
но это компилируется и работает ... link

#include <iostream>

consteval bool fn()
{
  return true;
}

int main()
{
  //static constinit
    bool b = fn();
  std::cout << b << '\n';
  return 0;
}

https://stackoverflow.com/questions/59925618/how-do-i-make-an-infinite-empty-loop-that-won-t-be-optimized-away

https://rsdn.org/forum/cpp/8600551.1

Автор: reversecode
Дата: 16.09.23

ох уж этот ктыв, все писаки ни одного читаки

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

R>>https://stackoverflow.com/questions/59925618/how-do-i-make-an-infinite-empty-loop-that-won-t-be-optimized-away

vsb>Спасибо, видел, но там толкового решения не нашёл, всё в итоге сводится к asm или нерабочие решения, была надежда, что что-то упустили на SO.

А чем asm не нравится, если это asm с пустым телом?
Ну вставь atomic_signal_fence(memory_order_seq_cst), это по сути то же самое, но без слова asm.

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

Pzz>Я вообще не удивлюсь, если в нонешнем стандарте нескончаемый цикл без побочных эффектов — это UB.

Да.

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

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

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

vsb>В голову, конечно, сразу приходит for ( ; ; ) {} но clang с оптимизацией этот цикл тупо выкидывает.
vsb>Можно ли это сделать на C, согласно стандарту и без ассемблерных вставок?

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

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

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

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

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

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

К>А какой смысл микроконтроллеру полностью нагрузить ядро?
Удваиваю вопрос. Сам уже полгода въезжая в тему микроконтроллеров, и пока не было нужды добавлять вечный безусловный цикл. Тихая оптимизация это, конечно, зло, стоило бы добавить предупреждение и для особо упоротых упорных добавить флаг -Wno-empty-loop.

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

К>>А какой смысл микроконтроллеру полностью нагрузить ядро?
C>Удваиваю вопрос. Сам уже полгода въезжая в тему микроконтроллеров, и пока не было нужды добавлять вечный безусловный цикл. Тихая оптимизация это, конечно, зло, стоило бы добавить предупреждение и для особо упоротых упорных добавить флаг -Wno-empty-loop.

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

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

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

К>Поэтому компилятор его и выкидывает: имеет полное право
Вскоре ему стандарт разрешит убивать людей и вот тогда он оторвётся по полной

К>А какой смысл микроконтроллеру полностью нагрузить ядро?
Точка ожидания отладчика, watchdog-а или ядра прогревают для проверки теплоотвода, выход по переключению контекста в прерывании.

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

di
hlt

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

Здравствуйте, 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>Почему именно неопределённое поведение, а не ошибка компиляции?

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

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

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

Да.

Я — Озимандия, я — мощный царь царей! Взгляните на мои великие деянья, Владыки всех времён, всех стран и всех морей!

P2809R2
Trivial infinite loops are not Undefined Behavior
Published Proposal, 2023-10-14
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2809r2.html

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

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

Именно поэтому надо ему помогать.

SP> Если человек не может правильно проверить переполнение так нефиг писать на С, пиши на Rust.

Вы бредите.
Перевести на Rust в сотню раз дороже, чем ввести в стандарт и все компиляторы выключение диверсионных фич там, где они не нужны, по явному запросу.
(Хотя лучше, наоборот, включение по явному запросу. Но это уже дело умолчаний компиляторов.)
А не нужны они в 95% кода практически любой программы.

Сейчас с этим кое-как справляются настройки уровня оптимизации, но это слишком грубо и непереносимо.

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

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

Почти так, но это скорее не карго-культ, а перетягивание каната, кто больше привлечёт денег за счёт того, что на пару процентов выходной код скорее, чем у конкурента, и в ком будут первым испытаны новые идеи.
Между GCC и Clang/LLVM происходит именно это, а всякие Phoronixʼы этому активно помогают.