Господа, Вы занимаетесь просто какой-то х.р..й ...
Вот это обертка в асм файле isr.s :


а вот это сам файл с обработчиками и примером:

Накладные расходы примерно 16МЦ... на фсе...

Кому х.р.я, а кому - сын ошибок трудных.
Т.е. получается, что __attribute__((interrupt)) и заставляет все call-used регистры сохранять внутри функции?

Как приятно иногда сказать: знатоки, блин.

Справедливости ради, такой подход имеет один побочный эфект,
прерывания будут разрешены еще до окончательного выхода из нашего
главного обработчика, НО, если прерывания идут с таким темпом что это
может вызвать переполнение стека, при других вариантах обработки мы просто
будем пропускать прерывания, так что такой вариант ИМХО вполне адекватный...

С __attribute__((interrupt)) прерывания будут разрешены сразу после входа в INT0_vect (INT0_vect), первой командой будет sei. C __attribute__((signal)) такого не будет, ИМХО правильнее __attribute__((signal,used)). К тому же вариант singlskv не универсален - переключаются векторы INT0, INT1, а если они нужны? В случае "просто" функций - компилятор выдаст предупреждение "misspelled interrupt handler" - из-за этого данный вариант мне показался не подходящим.
ИМХО в реале накладные расходы на if будут меньше push r30, icall и т.д.Не совсем понял иронию.

Не знаю, можно ли все, что я тут напишу, реализовать в GCC, но в IAR'е я бы делал так


Так меньше всего стека уйдет.

Что Ваш вариант в 20 тактов, что через icall в 21.
Тогда как банальный if(test) - 5 или 6 тактов - lds, and, breq.
ИМХО для 2 функций ни к чему. Навороты хороши не тогда, когда в комлекте ещё тормоза.

Дык я про то, что в моем варианте лишний стек не используется. По скорости это конечно тормоза.



А если их 22?

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


Сделаем необходимый инструментарий


WherePC заточено таким образом, чтобы возвращать 0 при вызове, а в параметре - адрес, с которого ее вызывали, исключая обработку возвращаемого значения.


Используя SubVector(имя_переменной_указателя_на_блок)


В итоге при первом вызове получаем адреса блоков кода в переменных sv[], но сами блоки не выполняем, по аналогии с setjmp, а при последующих вызовах - переходим в кратчайшие сроки к независимому блоку. В данном контексте это должно обеспечить выигрыш по сравнению со switch()

Просьба потестить эти примитивы и высказать мнения о применимости. Заранее спасибо.

Конечно там нужен signal а не interrupt.
На самом деле можно заюзать и несуществующие вектора,
и с учетом варианта обертки от Rst7 можно сделать вот так:
обертка в асм файле isr.s :

а вот это сам файл с обработчиками и примером:

а что если "раздеть" обработчик (__naked__), а на подставляемые функции наоборот, навесить сохранение контекста?

Не, там надо подставляемую функцию, к которой будут по указателю обращаться, делать (__naked__), а в нее заворачивать уже то, что нужно. С проктологической точки зрения - нормально двойной вложенный вызов. А с другой стороны оптимизация может выкинуть лишний call/ret.. надо попробовать

И потерять резервирование места под локальные переменные.

На мой взгляд, это отличный способ. Почему я так думаю - потому что:
1. Сохранение и восстановление всех регистров это всего лишь 128 тактов вход-выход в обработчик.
2. Как правило, необходимость в подмене обработчика прерывания происходит тогда, когда кардинально что-то меняется в работе программы, например - замена протокола обмена. В таких случаях логично предположить, что подменяемые обработчики "тяжеловесны" и по времени выполнения занимают гораздо больше 128 тактов.
3. Не надо гнаться за скоростью там где ее хватает, тем более в ущерб переносимости и читаемости кода.

Из чего делаем вывод - всего за 128 тактов получаем простой, прозрачный (легко читаемый), относительно безопасный, и прекрасно портируемый код на любую платформу.
Хорошо это, не очень хорошо, или совсем плохо - судить Вам ;>



Правда есть еще один тупой и топорный способ, о котором почему-то забыли упомянуть, хотя он обладает еще таким свойством как "абсолютная" безопасность :

при "сказочной" тупизне и кажущейся неоптимальности, вот какими плюсами сие обладает:
- Никакого гемороя с ассемблером.
- Тривиальная простота.
- Абсолютная безопастность - есть уверенность, что из обработчика выйдем всегда, и всегда выйдем правильно, нет риска неверного указателя в RAM.
- Возможность не только "подменять" обработчик, но и "параллельно" выполнять несколько обработчиков (например, по одному интерфейсу обслуживать несколько протоколов обмена).
- Легко портируемый.
- Нативно оптимизируемый - если все функции handler1, 2, и т.п. объявить в одном файле с обработчиком как static, то результирующий код получится эффективным - т.к. оптимизатор сделает свое дело сам.



Все шаманства с ассемблером и оптимизации "ради оптимизации" - это Зло. Лучше делать упор на функциональность, портируемость, читаемость. А вот когда действительно не будет хватать производительности и нет возможности поставить более шустрый кварц / камень, тогда (и только тогда) можно прибегнуть к извращениям на асм'е.

Есть несколько менее переносимый, зато более эффективный способ. В том смысле, что переписать эту субвекторизацию на другой асм другого процессора+компилятора можно, как можно и посмотреть реализацию структуры jump_buf и сделать переключатель, как у Rst7, привязанный к процессору+компилятору, но переписываемый под любую другую компбинацию. А тут - привязка к конкретному инструменту. Но раз в примере всё равно использован gcc, то... в нём можно взять адрес метки.
Во-первых, при этом можно WherePC сделать макросом, адрес вычисляется линкером:
И результат компиляции:

Во вторых, этот макрос при такой постановке вопроса не нужен вообще:
http://forum.sources.ru/index.php?showtopi...p;#entry1929594

В переводе на AVR-ский язык

И результат:

Да-а... На разных платформах количество переключаемого контекста настолько разное... У AVR- многовато


Спасибо!
Т.е. задача-то решается по-прежнему макросами(для совместимости), но адрес метки в gcc имхо самое не-кривое решение.