Коллеги!

Не использовал ли в своей жизни кто-нибудь clarm (Microsoft C/C++ compiler for ARM)? Есть интересное наблюдение. В модуле C1_ARM.DLL присутствует ключевое слово __interrupt, что наводит на мысли о поддержке в компиляторе данного выражения (так хочется этого). Но документация (скудная до ужаса) молчит на сей вопрос. Не сталкивался ли кто с этим?

А смысл?
Что ожидается получить от его использования?

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

1. А конкретизировать? Что такое экстравагантное потребовалось, до чего не додумалося НИКТО из
производителей компиляторов, но додумался MS. Какие надежды внушило вам абсолютно обыденное в мире компиляторв (тем более для embedded) слово "__interrupt"? Кстати, для ARMов оно бессмысленно,
ибо нужно иметь в компиляторе поддежку минимум трех вариантов для IRQ, FIQ и SWI.

2. Написание нескольких десятков команд на ASM "черевато" а перескок на странный компилятор
c "документация (скудная до ужаса)" это тогда чем черевато?

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

1. Ничего особо экстравагантного не потребовалось. Надо объявить функцию, которая вызывается по прерыванию. При этом ясно, что обычная функция и функция вызываемая по прерыванию имеют разные прологи/эпилоги.

2. Думаю, что Microsoft’овский компилятор не столь уж странен, если на нам написан WindowsCE под ARM. И уж не «страньше», чем многими любимый gcc. К тому же бесплатный.

3. Насчет нормальности такого подхода – это не факт. Совершенно ясно, что так (связка ассемблер + С/С++) делать можно. И так можно реализовать что-хочешь. Но мне при этом видится ряд неоптимальных решений. Первое. Приходится из ассемблерного модуля вызывать лишнюю функцию, написанную на С/С++. Второе. Так как вы понятия не имеете (если, конечно не заниматься такой веселой работой, как изучение ассемблерных кодов, порождаемых компилятором), какие регистры компилятор задействует в этой вызываемой функции, приходится записывать в стек на всякий случай все scratch регистры. Если бы функция, вызываемая по прерыванию, была бы написана непосредственно на ЯВУ c некоторым специальным ключевым словом (например, __interrupt), компилятор запихнул бы в стек только необходимый минимум регистров.

4. Потенциально можно вывернуться и по-другому, объявив функцию «голой» (__declspec(naked)), в inline asm’е самостоятельно прописать свой пролог/эпилог. Но в моем случае этот вариант не проходит, т.к. clarm не поддерживает встраевыемый ассемблер.

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

Реализована ли в компиляторе С++ Microsoft для ARM ключевое слово __interrupt?

Я перебробовал различные варианты вызова функций с этим спецификатором и наполучал лишь кучу сообщений об ошибках. Вполне вероятно, что __interrupt не реализована, или реализована каким-либо специфическми образом.

Ликбеза не надо - за десяки лет работы "я в курсе".
Я уже писал одним __interrupt на ARM платформе обойтись невозможно, ввиду разных правил
для разных прерываний. Это не X86. Посему, что значит __interrupt одному MS ведомо уж
не знаю, какими словами Вам еще это объяснить.
У MS вполне может быть заточен компилятор исключительно под приложения, со всеми вытекающими
последствиями. Возьмите любой нормальный компилятор и смотрите что-то типа
__fiq, __irq, __swh

Может не совсем в тему, но я лично уже давно отказался от __interrupt и т.п.
Небольшой эпилог/пролог на ассемблере при входе/выходе в прерывание и нет проблем. Например,
для irq (ARM720):
IRQHandler:
; Fix the return address
sub lr,lr,#4
stmfd sp!,{r0-r3,r12,lr}
bl IRQ_ISR_Handler -> моя п/п-обработчик, написанная как обычная (рядовая) ф-ция
; выход из пр-ия
ldmfd sp!,{r0-r3,r12,pc}^

Сделать _абсолютно_ то же, что сделает компилятор, только руками и не дай бог,
если вдруг другой 'C' компилятор решит какой-нибудь из r4.... сделать расходным и не сохранит
его при вызове Вашей функции.
Ну и сразу гагантированный вызов функции на ровном месте.
Короче, в чем смысл, при наличии штатной поддержки, естественно.

Ну просто не знаю как еще сказать, повторяю м_е_д_л_е_н_н_о еще раз: в тулзах от М$ нет абсолютного линковщика/локатора и его библиотека н_и_к_а_к не поддерживает ембеддный код, конечно можно извратиться и натянуть его как резиновое изделие на голову, но стоит ли сей спорт выделки? У меня есть знакомый, который адаптировал MS 7.0 под X86 embedded, так там от библиотек практически ничего не осталось, а процедура превращения результирующего экзешника в hex-ленту поражает своей алхимичностью...

Да нет там ничего сложного - EVC4, например, генерит код для WinCE в обычном формате PE. Я все собираюсь, да никак не найду пары дней для написания конвертировщика в hex. Если таки напишу - выложу с исходниками.
Оно того стоит - EVC очень приличный код выдает. Недавно коллега перекомпилил мой код с GCC3.2 на EVC4, блин, в процедуре загрузки ПЛИС через JTAG пришлось нопы ручками вставлять - настолько EVC код под XScale на скорость прооптимизировал. Единственное что - с документацией плоховато. Еще мне ассемблеры от MS не нравятся, но это уже мои персональные тараканы