Re: Interrupt handler attribute for m68k

Re: Interrupt handler attribute for m68k

[Mike Stump]

> Date: Tue, 15 Dec 1998 14:57:06 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>

> "__interrupt_handler__" was mandated by external forces :(

I would mandate people use 

#define __interrupt__ __interrupt_handler__

if they want this, I think egcs should be consistent and less subject
to `bad' decisions.  I think we should be willing to accept a fix for
this.

Re: Interrupt handler attribute for m68k

[Jeffrey A Law]

  In message < 199812152228.OAA06506@kankakee.wrs.com >you write:
  > > Date: Tue, 15 Dec 1998 14:57:06 -0700
  > > From: Jeffrey A Law <law@hurl.cygnus.com>
  > 
  > > "__interrupt_handler__" was mandated by external forces :(
  > 
  > I would mandate people use 
  > 
  > #define __interrupt__ __interrupt_handler__
  > 
  > if they want this, I think egcs should be consistent and less subject
  > to `bad' decisions.  I think we should be willing to accept a fix for
  > this.
I don't see the need.

This is a *MACHINE DEPENDENT* attribute.

I'll happily accept "__interrupt__" as a synonym, but I don't see the need
to be so rigid as to force folks to change code because we want all the
machine dependent attributes to look the same.

jeff

Re: Interrupt handler attribute for m68k

[John Breen]

From: Jeffrey A Law <law@hurl.cygnus.com>
>  > [...]  Which one would be the best to use as a model?
>Not sure.  Probably whichever port has code which most closely 
>matches the m68k's prologue/epilogue code.

Maybe I'm being naive about this.  From what I've been told, people 
currently use a wrapper like this for interrupts on m68k:

        movem.l %d0-%d1/%a0-%a1,-(%sp)
        jsr     c_function
        movem.l (%sp)+,%d0-%d1/%a0-%a1
        rte

My plan was simply to have the prologue code save these registers also 
if it's an interrupt handler, and the epilogue restore them and do an 
rte instead of an rts.  The rest of the prologue/epilogue code would 
stay the same.

If it takes much more than that, then I'm probably in over my head.
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Interrupt handler attribute for m68k

[John Breen]

I was thinking of trying my hand at implementing an attribute for 
specifying interrupt handlers for the m68k.  I see that it's been done 
for a handful of processors, but they all seem to do things a little 
differently.  Which one would be the best to use as a model?

The first question that occurs to me is what should the attribute be 
called?  Most seem to use __interrupt__, although one appeared to use 
__interrupt_handler__.  Then again, Motorola (at least) uses the more 
general term "exception", although I'll be happy to stick with 
__interrupt__ if it will minimize confusion.

Also, if anyone else is currently working on this (or started but put it 
on the shelf), let me know.
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Re: Interrupt handler attribute for m68k

[Jeffrey A Law]

  In message < 19981215214326.22090.qmail@hotmail.com >you write:
  > I was thinking of trying my hand at implementing an attribute for 
  > specifying interrupt handlers for the m68k.  I see that it's been done 
  > for a handful of processors, but they all seem to do things a little 
  > differently.  Which one would be the best to use as a model?
Not sure.  Probably whichever port has code which most closely matches the
m68k's prologue/epilogue code.


  > The first question that occurs to me is what should the attribute be 
  > called?  Most seem to use __interrupt__, although one appeared to use 
  > __interrupt_handler__.  Then again, Motorola (at least) uses the more 
  > general term "exception", although I'll be happy to stick with 
  > __interrupt__ if it will minimize confusion.
Use "__interrupt__".

"__interrupt_handler__" was mandated by external forces :(

jeff