ISR Argument Proposal Request

[gregory.menke at gsfc.nasa.gov]

Valette Eric writes:
 > Valette Eric wrote:
 > 
 > > Wait wait wait. I do not see the need of having access to the context 
 > > pushed on the stack for irq. I do see the need for exception handling.
 > > 
 > > In most RTEMS port, IRQ handling and execption handling are unified but 
 > > this is an error has exceptions are CPU scpecific (defined in the data 
 > > book) while IRQ frequently depend on board physical irq routing. Look at 
 > > PPC code or Ix86 code, they have two different API one for execption 
 > > handling and one for irq handling.
 > > 
 > > So please do not mix everything.
 > 
 > Thinking a little bit more, I furthermore think that the needed saved 
 > context in both case are differents : for real exception you need a full 
 > set of registers to try to recover from recoverable exceptions or for 
 > unrecoverable exception to debug your application (e.g remote debugging 
 > stuff). For irq, you only need to push the minimal set of registers 
 > needed to call a C function (usually the C scratch register defined in 
 > the ABI + some that you cannot avoid to use for low level (read raw) irq 
 > handling). So if we try to define the *right* context frame, we will 
 > never agree.
 > 
 > If Eric N. is listening, maybe he will comment on the various diffrent 
 > frame pushed by a 68030 or 38040 that depends on exception number and 
 > that you cannot manipulate so easilly.

The mips cpu_asm incrementally saves registers on a single fixed-size
frame; it initially saves the minimum registers so it can decode the
interrupt/exception, then vector it and ultimately dispatch.  

It only saves additional registers used by C when calling into C
(dispatch, isr vectoring, exception vectoring, gdb stub).  Depending
upon the cpu model, additional processor state is recorded on
exceptions, mostly for gdb's benefit.

Our exceptions are fatal/nonfatal as the vectors themselves decide,
cpu_asm will try to continue if the vector returns.  On the R3000, the
difference between an exception and an interrupt is very small and
handling them all in one routine with one type of stack frame has some
advantages.

Naturally, the fixed size frame necessitates a larger stack, but due
to the bazillions of mips variations, it does keep things simple.  The
only benefit I could see of using a variety of frame types on our
archtitecture would be to minimize stack overhead.  I imagine when on
something like a pci bus with bridges and several interrupt
controllers, it makes a lot of sense.  I think it would be a mistake
to try and decide on the format of a canonical frame, as it is so
architecture (if not bsp) dependent.  Perhaps it would be sufficient
to say that each architecture must define a "standard" stack frame,
whatever it may choose to do regarding additional frame types.

Overall, the mips isr/exception architecture is pretty efficient if
not very expandable.

Gregm