This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |