ISR Argument Proposal Request

[Joel Sherrill]

Till Straumann wrote:
> 
> Eric Norum wrote:
> > Joel Sherrill wrote:
> >
> >> change.
> >>
> >> Some issues that must be resolved:
> >>
> >>  + should rtems_interrupt_catch be backward compatable and
> >>    this functionality have a new entry point?  I lean to yes.
> >>  + should this feature be optional and conditionally compiled?
> >
> >
> > I'm pretty hesitant about conditional compilation.  There are an awful
> > lot of configuration time decisions already.  Complicating the process
> > further is just going to increase the confusion among new users.   The
> > argument for providing a way to turn off the feature is pretty strong
> > since the feature costs an extra 1k of memory bloat on M68k
> > architectures (256*sizeof(void*)).
> 
> Just an implementation detail: you could also think of the table being
> an array of pointers:
> 
> typedef struct {
>      void   (*hdl)(ISRArg *parg);
>      ISRArg  *arg;                          
               ^^^^^^^^^^

Ignoring rtems_ style on names, are we saying that it is a
pointer to a known structure (ISRArg) of should it be

typedef void *ISRArg;

and the "*" above not there.

>      /* more items as needed by the API */
> } ConnectDataRec, *ConnectData;
> 
> ConnectData isrTable[NUM_VECTORS] = {0,};
> 
> ISR installation would then allocate a structure and attach it to the
> correspondent vector's table slot. On many architectures, the
> extra deref step needed is not more expensive (if not cheaper) than
> the 'vector * sizeof(ConnectDataRec)' computation needed accessing
> a table of structs. 

But on many architectures, the above is 8 bytes long which is an
incredibly
cheap offset to compute.  Worst case is to shift the vector number left
3
bits.  

It depends on how much data the port adds.  It if turns out to be a hard
offset to compute, then the porter should reconsider. :)

> OTOH, the dispatcher would have to perform an
> additional NULL pointer check
> 
> ( if (isrTable[vec] && isrTable[vec]->hdl)
>        isrTbl[vec]->hdl(isrTbl[vec]->arg); )

I don't like adding the extra allocation of vectors.  There is memory
overhead in getting it from the heap in addition to the extra check
required.

> > I'm dithering here, but at the moment I guess I'd argue for
> > 'conditional, but default is to include'.  (Sort of like the Canadian
> > Prime Minister who stated, ''Conscription if necessary, but not
> > necessarily conscription.'')
> 
> I repeat my mantra here: providing the arg is so cheap (space + runtime)
> that the efforts of maintaining #ifdef branches is not justified.

For the sake of getting this done, I will buy that for now.  There are
other areas in RTEMS where fat can be trimmed.  

> >> The development plan needs to have volunteers for each of the following:
> >>
> >>   + generic change from table of handlers to table of
> >> handlers/arguments
> >>   + each port's irq handling
> >>   + API changes to original interrupt API, ppc, x86, and ARM
> >>   + documentation changes
> >>   + any work break down I am missing?
> >>
> >>   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 do the M68k assembler changes if no one else can be found.
> 
> Great :-)

Please keep a list of who is volunteering for which port.  I will
try to be a backstop for the other ports.  I can program any of them
but it would be faster for someone who uses a CPU on a daily basis.
I have to remember a lot. :)

> -- Till
> 
> > Also, I think this has been decided already, but if we're going to open
> > up the code and make these changes I vote for a 'void *' argument to
> > interrupt handlers.
> >

-- 
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