This is the mail archive of the mailing list for the crossgcc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: m68k & Interrupts

> Date: Tue, 15 Sep 1998 08:27:20 -0700
> From: (Art Berggreen)

> >I compile the interrupt routine with the switch that causes it to stop 
> >after translating to assembler.  I hand-edit it, changing the rts opcode 
> >to rte.  Then I assemble it and link.
> In the standard m68k C function call interface, the called function is
> only required to preserve the contents of registers D2-D7 and A2-A6
> (A7, the stack pointer, should end up back at the same value).  D0, D1
> A0, A1 are considered volatile across a function call and the compiler
> tends to use them as work registers.  D0 (and sometimes D1) is used to
> return the function return value.
> Because of this, your hand edited code will allow the contents of
> D0, D1, A0, A1 to be corrupted by an interrupt, causing unpredictable
> (and hard to debug) problems.
> You could just add a "movem.l %d0-%d1/%a0-%a1,-(%sp)" to the beginning
> of the function and a "movem.l (%sp)+,%d0-%d1/%a0-%a1" before the rte.

My observation is that gcc, if it uses registers other than the scrachpad 
ones mentioned above, will emit movml instructions to save these registers
on the stack, and restore them before the return (it seems to emit a numeric
register select field rather than the symbolic one above).

Rather than hand-editing, you could write an awk/sed/m4 script to add the
bits for the scratchpads to the movml masks, as well as altering rts to rte.

There is a snag in that gcc might not emit the movml's because it only
uses scratchpad registers.

The other snag is the link/unlk instructions to set up the frame pointer.
These cause no real harm, as a6 is restored, but I think they do little good
either, particularly as you don't generally use a debugger on interrupt 
handlers. You can stop gcc emitting these with the -fno-frame-pointer option,
but only on a module-by-module basis.

Maybe this helps,

Robin Kirkham			CSIRO Manufacturing Science and Technology
Project Engineer		Locked Bag 9, Preston 3072, Australia	Phone: +61 3 9662-7756  Fax: +61 3 9662-7853