ISR Argument Proposal Request

[Joel Sherrill]

gregory.menke at gsfc.nasa.gov wrote:
> 
> Joel Sherrill writes:
>  >
>  >
>  > gregory.menke at gsfc.nasa.gov wrote:
>  > >
>  > > Joel Sherrill writes:
>  > >  >
>  > >  >   NOTE: When you change a port, I would consider that to include
>  > >  >   getting all the BSPs modified.  Everything should still build.
>  > >  >   I regularly build all BSPs so this is somethign I can provide
>  > >  >   feedback on.
>  > >  >
>  > >  > We can't start this until we are confident all
>  > >  > the ports will get updated.
>  > >
>  > > I can work on the mips side and test it on our hardware once theres
>  > > consensus on the implementation.
>  > >
>  > > I would like to preserve the ability to pass a pointer to the stack
>  > > frame to the vector, preferably as an extra argument to the vector
>  > > call itself.  This is essential for some of our interrupt processing
>  > > and avoids unpleasant hacks.  In fact, we don't use the vector # at
>  > > all at present.
>  >
>  > 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.
>  >
> 
> 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.

The differences in ISR handler prototypes across the ports creates
irritation for me.  If any effort is being expended in this area, I
would like to see it become consistent.  That way code can be used
across ports with less pain, warnings, and calling variations to 
deal with.  

> 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 #.
> 
> Gregm

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985