M68K C Interrupt Handler

Alex Holland alexh@stellarwinds.com
Sun Apr 1 00:00:00 GMT 2001


Agreed. In my particular case, each interrupt handler is almost identical.
In between save and restore registers, it calls  kernel ThreadEnterIsr() and
ThreadExitIsr() routines, jumps to the real handler registered by a device
driver, and does CPU end-of-interrupt processing. I wanted to keep as much
CPU specific and kernel specific interrupt handling detail out my device
drivers, and my legacy HW has the vector table in ROM.  I intended to convey
by the save/restore register macros in my example that the appropriate
registers should be saved/restored for the interrupt. If this were different
for each interrupt handler and performance was very important (else I could
just save/restore all registers), it would be a pain. However, it does not
appear that this, okay kludge, is causing me a problem, but I am still
debugging ... My long term solution will be to install the patch that Ken
Desmet was kind enough to send me and rebuild my environment.

Alex

----- Original Message -----
From: "Peter Barada" <pbarada@mail.wm.sps.mot.com>
To: <HollaA@HPD.Abbott.com>
Cc: <crossgcc@sources.redhat.com>
Sent: Thursday, January 18, 2001 2:55 PM
Subject: Re: M68K C Interrupt Handler


>
> >Note that I did not use a "wrapper method" and therefore avoided the
> >overhead of the jsr. I simulated the effect of the interrupt attribute by
> >globally labeling the section of code directly in front of the function
> >prologue and then entering this label in my vector table. I also used
inline
> >assembly to save/restore registers and return from interrupt.
>
> You have to be very careful about jumping/vectoring to labels inside
> of a function.  If there is a register that is used that can not be
> stuffed into d0/d1/a0/a1, then the function prologue (which can be
> before the label you vectored to) has to save the register, and the
> rte that you added at the end is before the epilogue which restores
> the other registers.
>
> Of course if your handler is simple this isn't a problem, but you'll
> have to look at the assembler output of the compiler to see exactly
> how its generated code interleaves with your asm statements.
>
> --
> Peter Barada                                   Peter.Barada@motorola.com
> Wizard                                         781-852-2768 (direct)
> WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)
>
> ------
> Want more information?  See the CrossGCC FAQ,
http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to
crossgcc-unsubscribe@sourceware.cygnus.com


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



More information about the crossgcc mailing list