Это только в том случае, если они освобождаются вместе с окончанием той функции/блока, в котором были заведены. Но main() свои локальные переменные (те, что заводятся в ее начале) не освободит никогда - на то у нее и бесконечный цикл внутри сидит.

В данном случае разговор зашел о том, что инциализация/сброс стека приведет к пропаже локальных переменных внутри main(). Так я и выразилась в том духе, что заводить внутри main() локальные переменные смысла не имеет. Т.е. речь шла не об экономии памяти, как вы это неверно поняли, а об устойчивости переменных к сбросу стека.

P.S. Не стоит обольщаться тем, что войдя джампом из прерывания во внутрь какой-то функции (в том числе и main), вы обнаружите там локальные переменные на тех же местах. Адреса локальных переменных отмеряются относительно текущего указателя стека, который при запрыгивании со стороны никак не может быть правильным (т.к. функция прерывания тоже пользуется стеком). Поэтому как ни крути, но валидными в этом случае могут быть только глобальные переменные, но не локальные. Причем независимо от того, сбрасывали вы стек или нет.

Тут поддержу Ксению, но какое это имеет отношение к вопросу топикстартера? Он же сказал, что состояние программы и стека ему не известно и не важно. Возможно, стек переполнился и залез на глобальные переменные. Надежнее не использовать вообще никакие заранее определенные переменные. Используйте константы или заведите новые переменные, порушив глобальные, переставьте указатель стека на начало и вперед! Только вперед и только хардкор

_Артем_ ответил по всем пунктам.
Касаемо последних двух сообщений: компилятор не может знать вашей логики, заставить его "не использовать локальные переменные" нельзя. Решение с goto из одной функции в другую ущербное каким бы хаком оно бы ни было реализовано. longjump() еще куда ни шло - он поддержан компилятором.
Было же грамотное решение - функция с атрибутом noreturn. И вызывать ее как функцию, без всяких указателей и т.д. Компилятору этого noreturn по идее должно быть достаточно, чтобы не сохранять лишние регистры в каждом прерывании.

Во-первых не надо считать компиялтор настолько тупым. Во-вторых и внутри этого бесконечного цикла имеют право быть несколько блоков со своими локальными переменными.
То есть еще одна распорка чтобы конструкция перевязанная предыдущей расчалкой не навернулась.
Именно поэтому setjump() сохраняет состояние указателя стека. И после longjump() все локальные переменные находятся на своих местах совершенно нетронутые.

Совершенно непонятно: почему ТС не хочет использовать setjmp / longjmp ? ИМХО, это - хорошее решение той задачи, что стоит перед ТС, абсолютно стандартными средствами. Даже пример, взятый мной из GCC и приведенный в сообщении #9, почти один-в один совпадает с тем, что желает ТС и привел в первом сообщении. Жалко места под буфер jmp_buf ?
Решение же проблемы почему-то "крутится" вокруг goto... Зачем этот "гемморой" ?

ТС не хочет чтобы в прерывании куча регистров сохранялась-восстанавливалась: ссылка

так ведь это как бы и требовалось?

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


у меня была идея поместить эту функцию в секцию .fini1 и попадать туда стандартной функцией exit или abort, но компилятор оказался слишком глупым и тупо сохранял в стеке все регистры в обработчике прерываний...

Да, это оно самое и есть, чего хотел ТС.


Не, не проинлайнится. noreturn роли не играет.
Видимо регистров мало сохраняется из-за того что goto используется.



А если так:

то лишних сохранений не будет и функцию можно расположить по заданному адресу.

Что-то непонятно. Что значит "программа должна завершиться", если в ней есть main с бесконечным циклом? И что будет если из main дать return?

Если нужно заблокировать работу программы находясь в прерывании - запретите все прерывания и зациклитесь. Из этого можно можно выйти только по reset.

Перейдёт на какую-нибудь функцию exit (или что там предусматривается на такой случай).
Как-то так оно выглядит:

Но можно и своим чем-то заменить.


Возможно таких мест не одно. И там предполагается не только зацикливание, а ещё какие-то спасающие ситуацию действия.

-Os
нет, код после метки отстается, возможно что там используются volatile-переменные


Идея с семафором, ветвлением вначале main и оригинальная, но все же я не очень доверяю сохранности портов после сброса ..


этот вариант не подходит т.к. по сути это тот же самый вызов функции с вытекающими последствиями


Помоему самое оптимальное решение !
т.к. даже через снятие адреса метки:
компилятор заменяет на ijmp ptr что задействует еще пару регистров, которые сохраняются в стек
Только неясно почему опять кривой костыль ?

Может быть.


О каких портах речь? Входы-выходы? После сброа они будут сброшены в дефолтное состояние.


Есть, кстати ещё вариант: в прерывании, в котором обнаружена аварийная ситуация генерить вызов другого прерывания в котором и выполнять нужные действия (уход в sleep кажется?). Программное прерывание то есть.

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

тот вариант о котором говорила Xenia
#17
с вызовом прерывани из прерывания я тоже думал , как вариант , но всеже rjmp проще всего

Всё это (аварийный выход) стоит завернуть в какой-нибудь макрос с внятным именем типа abort();
Кстати, вариант с программным прерыванием - ИМХО самый оптимальный - вызов одна инструкция sbi, ну и обработчик со всеми нужными атрибутами...

В AVR программное прерывание "сгенерить" не так-то и просто. В АVR, обычно, запись единицы в флаг прерывания приводит к её сбросу.

На худой конец можно задействовать и внешнее прерывание + дёрнуть уровень на ноге sbi или cbi или просто его разрешить на нужной ноге с нужным уровнем.
Всё это уже лирика...
Ведь не зря же его для нужд rtos частенько используют...