[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ISR Argument Proposal Request

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
cheap offset to compute.  Worst case is to shift the vector number left

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

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