ISR Argument Proposal Request

[gregory.menke at gsfc.nasa.gov]

Valette Eric writes:
 > Joel Sherrill wrote:
 > >
 > > 
 > > I hesitated mentioning this but in fact a handful of 
 > > ports which pass a 2nd argument which is the address of the
 > > exception/interrupt stack frame.  The format of the data
 > > at that pointer is port defined although I believe the
 > > name of the data type is universal.  So I would REALLY
 > > like to see:
 > > 
 > > void _ISR_HANDLER( void *, frame * );
 > > 
 > > with better names.  :)
 > > 
 > > The frame * is generally also known at ISR vectoring time.
 > > 
 > > 
 > >>WRT backwards compatibility, as long as we can continue symbolically
 > >>refer to bsp-specific interrupt lines when calling
 > >>rtems_interrupt_catch, most any changes are fine with us.
 > 
 > 
 > 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.

On our R3000 (at least), floating point exceptions paradoxically come
in as interrupts, so the stack frame is essential.  In addition,
computing the vector (and vector array index) consists of fairly
trivial bit shifting, so its quite efficient- which is critical on our
12mhz processor.

Gregm