Возможно я был не прав в своих заблуждениях. Давайте разбираться. То, что остальные регистры сохранятся при вызове функции вовсе не значит, что прерывание может их испортить. К scratch относятся R0-R3, R12. При возникновении исключения IRQ (а именно о нем шла речь в контексте многих обработчиков) переключаются только R13, R14 и значит общая "обертка" должна сложить на стек все 5 scratch регистров, ибо не имеет информации какой из них будет испорчен в конкретном обработчике. Если же мы даем компилятору возможность для каждого обработчика сгенерить свои пролог/эпилог, то для некоторых прерываний, в которых не все scratch регистры портятся, компилятор имеет право сохранять/восстанавливать только используемые (экономятся такты и место на стеке). Едем далее - в каждой самой "внешней" функции обработчика компилятор должен сохранить preserved регистры, которые используются. В случае индивидуального пролога/эпилога он может объединить в одну команду сохранение scratched и preserved регистров (сэкономив такты и код), а в случае общего пролога/эпилога ему придется делать две команды - сохранение scratched в прологе и сохранение preserved в теле обработчика. Аналогичные выкладки для эпилога.

Где ошибка в рассуждениях?
Если вы это про мой пост, то особенно хотелось бы услышать Ваши контр-аргументы.

Насчет умной функции обработчика прерывания. Думается тут как обычно - проблема теории и практики. Все аргументы, которые приведены - абсолютно правильные. Но. Предположим, что из функции обработчика прерывания вызывается еще какая-то "не умная" функция, которая обычным образом использует scratch регистры. И что делать тогда? Запретить вызовы функций? Выполнять какой-то изощренный анализ используемых регистров? Думается, что это одно из объяснений, почему многие производители компиляторов это дело похоронили.

Тогда будут использоватся наряду с собственными регистрами и R0..R3. Эффект от использования FIQ уменьшится, но не исчезнет. Кроме того, 'развесистые' обработчики FIQ так или иначе не влезают только в FIQ регистры и использование общих регистров этом случае начинается с scratch регистров.
Все вполне эффективно получается и без 'изощренного анализа'.

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

'Обьяснений' ничего не объясняющих было уже много. Может достаточно?

Ничего себе сколько тут уже понаписали... Вообщем-то вопрос насколько я помню, ставился так: умеет ли RealView работать с FIQ или нет. Оказалось что нет. И вполне понятно, что чтобы полностью использовать все прелести FIQ в данном компиляторе надо писать на ASM.

Тут кто-то просил исходники...

Это что касается обработчика


А это в стартапе



Так вот, у такого подхода, кроме того что такой обработчик будет вызываться немного быстрее чем просто IRQ, неожиданно появился новый плюс.
В проекте используется операционка RTX от Keil, в которой соответственно используются прерывания от таймера. Мне необходимо записывать во внутреннюю флеш. В IAP в момент записи нужно запрещать прерывания или убирать их в RAM. Однако нужно чтобы I2C все равно работал в момент записи.
В итоге, в теории, чтобы не ковыряться с прерыванием от таймера в RTX, можно запретить все IRQ на время записи/стирания флеша, а обработчик FIQ для I2c поместить в RAM. Кроме того для работы FIQ достаточно в RAM поместить только сам обработчик, так как его адрес лежит в регистре.

Щас попробую све это забацать. Посмотрим как будет работать.

Дальше действует Procedure Call Standard for the ARM® Architecture. Т.е. необходимые scratch регистры сохраняет вызывающая функция, preserved регистры - вызывающая. Все равно остается поле для оптимизации. Собственно я защищаю только одну фразу:Именно это является преимуществом индивидуального пролога/эпилога. Недостатком является увеличение кода.

Ну а процессор настолько умный, что сам из регистра вектор копирует в R15 :-)

PS. При одном FIQе прописывать VICVectAddrX вообще-то не обязательно.

Да, насчет векторов я неправ. Адрес обработчика FIQ тоже во FLASH лежит...
А в VICVectAddrX я ниче и не писал.

Именно для таких случаев существует remap. Но его применение требует внимательной линковки.