C-be nem is lenne értelme ilyet berakni a standard-ba szerintem, ha mögé gondolunk a dolgoknak. Ezért nincs benne, nincs mindenhol értelme, a C pedig megpróbál általános lenni.
Igen, a C az elegge altalanos, de minden ami a protected/privileged/escalated/interrupted/trapped/etc temakorrel kapcsolatos az nagyon specifikussa teszi. Nem is a nyelvet magat, hanem a "koritest". Igazabol igy "okolszabalynak" azt mondam hogy a C forditok (pl GCC) adnak egy relative egyszeru metodust arra hogy a "tankonyvi pelda" jellegu megszakitasokat kenyelmesen irj. Ezekben az esetekben altalaban valami #define-olt makrot, __attribute__-ot, stb kell ele-moge irni a megfelelo handlernek, es akkor a fordito megcsinalja azt amit kell (a regiszterek/allapotok kapcsan menti amit menteni kell majd visszaallitja, megfelelo interrupt return utasitassal ter vissza a sima return helyett, beleteszi a megfelelo vektorokat/jmp-ket a a vektortablaba/jmp tablaba ha kell, stb). Ha van hardveres/beepitett/mikrokodolt segitseg (mint pl az ARM Cortex-Mx kontrollereknel) akkor ez annyira ki tud egyszerusodni hogy semmit nem kell a handler ele-moge irnod :) Ld. fentebb, valahol. Ezekben az esetekben tehat egyreszt semmi asm-tudas nem szukseges, masreszt viszont nem art tisztaba lenni a megfelelo function attribute-k kimerithetetlen hosszu listazasval hogy tkp mi mit csinal (avagy a makrokat ezek egyszerusitesere meg kismeretkben valo hordozhatosagara keszitettek fel).
Viszont olyan esetekben amikor a tankonyvi peldaknal komplexebb valamit kell megoldanunk, akkor mar igen jo esellyel nem usszuk meg sem az assembly-t, sem a fenti function attribute-k meg kimeritobb tanulmanyozasat. Persze ez az allitas is erosen ketseges lehet, pl az is erosen rendszer-fuggo meg kicsit szubjektiv is hogy mi szamit "tankonyvi peldaknal komplexebb valami"-nek, de egy context switch vagy illegal instruction fault handler mar joesellyel ide tartozik.
Es hogy a kivetel gyengitse a szabalyt, meg ilyesmikkel is lehet talalkozni mint struct interrupt_frame *. Ezt abszolute nem ismerem a gyakorlatban, de nem kizart hogy ezzel pont a "tankonyvi peldaknal komplexebb valami"-k egy reszeben is ki tudunk szabadulni az assembly-zes kenyszerebol. Legalabbis hasonlo elgondolasokat lattam mar RISC-V BIOS-ok (SBI-k) eseteben, ahol ugyan kezzel, de egy teljesen egyseges interrupt handlert allitanak be ami utana minden esetben a szabvany C ABI szerint adja at a teljes kontextet barmilyen okbol kifolyolag is hivtak meg a handlert (azaz ugyanaz hw interruptra, sw interruptra es trap-ek eseten is, sot, exception/interrupt delegation eseten is). Raadsul RISC-V eseten az eggyel kisebb privilegizalasi szinten futo op rendszer (pl. linux kernel) is ezt csinalja. Azaz siman el tudom kepzelni azt hogy egy megfelelo __attribute__ legeneralja ezt a kodreszletet egy masik/adott architektura eseten es onnantol kezdve szabvany C ABI szerint mennek tovabb a dolgok a maguk utjan. Kicsit hasonloan mint a Cortex-M eseten, csak egyreszt nem prociba vasalt mikrokoddal hanem sajat koddal, masreszt meg az ABI ott nem void handler (void) lesz hanem void handler (context_t *) lesz.
tldr: elegge vegyes az osszkep, igen.