В ассемблере так часто делал. Стек разгружал. А в Си так можно?

Если нужно конкретно платформа - Keil5, контроллер STM32.

Формально - нет. Да и неправильно это, как компилятор отследит разный calling convention, да еще и с varargs

Для этого есть функции setjmp и longjmp, но запутать таким образом программу и заложить трудновыявляемые глюки элементарно.

ой, "два CALL и один RET" или даже "два CALL и один JMP" стек не то что разгрузят, но "испортят" хоть в C хоть в ASM (не вернут в прежнее состояние, будет некий StackLeak который при таких N-вызовах порушит всё )
вы уверены в своих ранее написанных программах ? Или может я что-то не понимаю

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

pop sp, Dec sp и jmp. Да, 15 лет до сих пор пашет.


Попробовал setjmp и longjmp. Работает. Но раз моветон, применять не буду. Самому не понравилось такое решение.

И вы гарантируете одинаковость имплементации такой конструкции на всех процессорах? Что первично, inc/dec или mov?

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

Конечно нет. Я для 8051 писал. Мне на "все" и не надо было.

Если "нельзя", моветон, но "оченьнадо". Оченьнадо - это авария по питанию.
Есть в моем проете один longjmp. Обеспечивает "выпрыгивание" из вектора прерывания в блок,
находящийся в начале main().

Да ладно. "Моветон" и т.п. - что за пуританство? Если это улучшает читаемость кода и стройность алгоритма, то применять можно и нужно.
Сам так иногда делаю. Когда нужно вернуться в предопределённое положение (функцию) из дерева вложенных вызовов из множества мест. Реализовывать такое на специальных возвращаемых значениях (в каждой функции, из которой может быть такой возврат!) - это будет куча лишнего кода.
Куда элегантнее и прозрачнее будет восстановить стековый фрейм.
А насчёт "на всех процессорах": а это реально так нужно? А ничего если в используемой ОС тоже есть ассемблерные вставки и перенос её на другое ядро производится написанием порта под нужное ядро? Кто же мешает так сделать и в этом случае? Тем более что кода тут - с гулькин нос.

В конце концов: си (или ++) - это инструмент, а не самоцель. А цель всё-таки - это наиболее эффективное решение задачи (написание эффективного ПО).

PS: си-шными setjmp/longjmp я не пользуюсь. Пишу свои асм-функции сохранялки/переключалки стекового фрейма.

Это даже у системных программеров под Винду (конкретно мы, группа, реализовывали свой драйвер COM порта, ...15 лет назад) было моветоном.
Можно писать как угодно коряво, но лучше красиво. В грамотных ассемблерных вставочках комментарий в каждой строке. Код должен своим видом показывать, что он правилен. Как-то так ИМХО.