ISR Argument Proposal Request

[gregory.menke at gsfc.nasa.gov]

Valette Eric writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > 
 > > At present cpu.h provides a per-cpu #define for conditionally
 > > including the 2nd stack frame parameter- its not accessible by
 > > configure.  Perhaps that approach could stay if people desire it- a
 > > 2nd parameter is inexpensive on mips, but not necessarily elsewhere.
 > > 
 > > I've come into this discussion a bit late, my interpretation of the
 > > discussion is people are contemplating changing the vector table to an
 > > array of structs, one per vector, which contain the vector address and
 > > a user-supplied void * which is passed with the vector call.  Each bsp
 > > will index into the array as it suits the architecture- the advantage
 > > of the structs being it allows the programmer to supply something
 > > useful rather than having to interpret a vector # or creating a pile
 > > of small functions to do it.  Is this right?
 > > 
 > > On the mips, we vector exceptions from the same table as interrupts,
 > > which I think is a wash in this case as we would set the void * to the
 > > exception #.
 > 
 > I think you should have a look at the PPC implementation of irq handling 
 > because we are discussing different things here. The handler table and 
 > the irq handler argument do not need to be in the same table, just on 
 > many arch it will save instructions to do so as the hdl and its argument 
 > are "close".
 > 

I'm not wedded to our vectoring implementation.  It was a convenient
choice at the time given the state of the mips support in RTEMS, but
something more sophisticated would be fine.

I've been messing around in the PPC bsp a bit, and from my fairly
short exposure, I think something like that would be OK.  I'm willing
to deal with the local tweaks we might need to pass additional state
around and the enhanced portability would be a big help.

Gregm