Возникла ситуация когда при обработке прерывания нужно изменить привычный ход программы, когда содержимое сохранненых регистров и указатель стека уже не важны. Оператор goto тут не работает:

Что можно здесь сделать ?

Просто из прерывания вызываете другую функцию, зачем вам в main возвращаться, если вам не важны стэк и регистры.

Не знаю как на СИ.
А на асме записываю в стек нужный мне адрес и ret

Функции setjmp / longjmp подойдут ?

Проще всего в программе установить семафоры с ветвлением по if или switch, а из прерывания эти семафоры переключать.

не могу перегружать память сохраняемыми регистрами
в теме была описана ситуевина: http://electronix.ru/forum/index.php?showtopic=112377

на Асме я бы просто rjmp написал

похоже нет

похоже нет

я так и поступил , но всеже хочется разобраться с "прыжками"

А регистры сохраняются? Вы смотрели?

Так и напишите

По выбранному адресу расположите вашу функцию (Си или асм)

Изврат это какой-то, чего с ними разбираться.

Смотря какой проц.

Ну, отчего же...
Вот, почти полное повторение того, что Вы хотели

почти все старшие регистры, независимо используются они или нет

Метки как значения давно есть в ГСС. 4.3 Labels as Values

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

А прыгать нельзя! Мало ли в каком состоянии стеки находятся в том месте, откуда сигануло в прерывание? Вы, положим по метке перейдете, а стек кто чистить будет?

Например, была вызвана функция, которая при входе создала кучу малу локальных переменных на стеке. Потом эта функция вызвала другую функцию, которая сделала то же самое. И т.д. А тут в тот момент, когда процессор в самой глубокой фунции код выполнял, ваше прерывание и приспичило. И куда вы теперь пойдете, когда стек полным-полнёхонек?

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

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

Помоему то что нужно!
Но всеже както странно , первый раз вижу оператор '&&' в таком применении. Это какаято особенность GCC стандарта ?


Xenia такой сценарий Если уж выполненно определенное условие , то стек и состояние др.регистров неважно

Точно! программа должна выполнить определенные действия и завершиться.

Если брать микроконтроллеры то там редко когда программа завершается, передавать управление некому, запуск только через включение питания (ресет).

Lagman подал хорошую идею. Разовью.
Ветвление надо произвести только один раз - в самом начале main(), еще до вхождения в бесконечный цикл.
Что вроде того:

В прерывании же при обнаружении экстренного случая взводится светофор (semafor = true) и программа запускается с нулевого адреса (setjmp 0).

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

Если нужно завершить программу, то почему бы не сделать возврат из прерывания не в точку вызова, а туда где лежит фнкция завершающая программу?

Да, это GNU расширение стандарта "С". В Вашем случае я бы использовал для восстановления микроконтроллера функцию с атрибутами static inline, а потом пересбросил бы микроконтроллер.

Тогда отчего бы не написать завершающую функцию прямо в прерывании?

Можно и написать, но наверняка тогда прерыванию потребуется больше регистров для завершения(количество регистров зависит отсложности действий при завершении), которое выполнится один раз. То есть прерывание всегда будет сохранять-востанавливать много регистров.
А если сделать по-моему варианту, то может быть прерыванию регистров меньше понадобится(но вариант с jmp лучше чем ret). Но работа программы завершится и возобновлена может быть только после сброса.

Если достаточно "мягкого" рестарта, то семафор заменяет пара функций setjmp / longjmp.

Вообщето я так и хочу сделать, только не в функцию , а в участок main

А вы уверены, что этот участок адекватно отреагирует на мусор в стеке?

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

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

установить-то можно. Вот только main() может выделить на стеке место под переменные лебединой песни и даже, возможно, разместить там заранее какие-то значения. И при установке указателя стека на начало получим обращение к несуществующей памяти, а при переходе с кучей хлама на стеке будем обрабатывать мусор. Поэтому все и пишут, что решение ущербное по условию..

если очень хочется, то можно вот так:при желании my_exit() можно вызывать и в main, не нарушая общей структуры программы. хотя с моей точки зрения это кривой костыль, правильное по моему мнению решение я озвучивал ранее.

Нормальные люди в main() локальных переменных не заводят! Что проку от их локальности, если main() никогда не завершается? Переменные, используемые в main(), лучше объявлять глобальными - результат тот же самый, зато стек не расходуется впустую. А если не хотите, чтобы эти переменные из других модулей были видны, то объявите их static.

Смишно.


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


Зачем? Лучше их сделать локальными, тогда точно не будут видны.


goto заменилось на JMP my_exit без ненужного сохранения регистров. Надо же...

Это только в том случае, если они освобождаются вместе с окончанием той функции/блока, в котором были заведены. Но 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 частенько используют...

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


Так в каждом из этих мест сделать то же самое, предварительно совершив "спасательные" действия.

А чтобы после reseta понять что именно случилось - можно записать что-то в память или во флешь. А в начале программы (от reset) поставить анализ этого со стиранием в исходное состояние.

Как раз Xenia это и предлагала:



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

В чем именно ущербность goto ?

Пора голосовать, хто за setjmp/longjmp ?