Re: M68K C Interrupt Handler

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Peter Barada wrote:
> 
> >I wanna how do  you know the compiler will save other register
> >autimatically?
> 
> The calling convention that most(if not all) compilers follow(for
> m68k) is to save/restore any register that they modify *except*
> a0/a1/d0/d1.  I'm ignoring the FPU registers since this is for m68k
> only.  This convention has been around for about as long as the m68k
> has.

 The 'calling conventions'-section, for instance in the 'embed.pdf' in
the RedHat GNUPro docs, will tell this for m68k too...
 
> So if the interrupt handler saves a0/a1/d0/d1 and then calls a C
> function, that C function and any of the C functions that it calls
> will save/restore all the registers, and upon return to the interrupt
> handler, restoring a0/a1/d0/d1 and executing the rte will return back
> to the point where the interrupt occured as if nothing happened.

 A generic wrapper can be nice, but sometimes no registers will be needed
to save/restore. The 'm68k' is one of those weird CPUs which can set/clear
bits straight in the memory places without any RISC-like 'load/change/store'
operations. At least in theory, the 'volatile bug' in GCC causes these
'load/store' operations being generated even when they could be avoided...
So the wrapper blindly saving and restoring the a0/a1/d0/d1 when none of
these were used in the ISR, causes unnecessary overhead.

 The GCC compiler generating the ISR prologue/epilogue automatically for
'#pragma interrupt' or '__attribute__((interrupt))' will then produce
a more optimal ISR. Also the extra function call from the wrapper and the
return to the wrapper add still more overhead...

 Achitectures with vectorized interrupts will benefit if the prologue and
epilogue are parts of the stand-alone ISRs.

 For architectures where all interrupts are routed via the same address,
or grouped into some few addresses for different priorities (like Matsushita
MN10200), implementing the ISR support in GCC would be vain... The generic
wrapper with the code to resolve the reason for the interrupt and the start
address of the service routine is the way to go there...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com