API modification request

[Joel Sherrill <joel@OARcorp.com>]

The list of cc's grows. :)

Ralf Corsepius wrote:
> 
> Am Die, 2003-02-04 um 00.35 schrieb Joel Sherrill:
> > Till Straumann wrote:
> > >
> 
> > > 3) Ralf: passing an ISR arg is not supported in hardware on all
> > >           CPUs (e.g. SH1), additional lookup needed.
> >
> > This is OK I think because even the code in sh7032/cpu_asm.c has
> > to figure out the vector number to invoke the handler.
> Yes, but ..
> 
> >  So it is
> > only 1 logical step away from being able to index into a table
> > of pointers.
> This is probably true on the caller-side, but I am not sure about the
> impact on the callee-side, if looking up an IRQ argument from inside the
> ISR is required. I suspect this penalty to be handful of instructions
> and to be several dozens of wait-states. Memory consumption for lookup
> tables might also be a concern (1-wait-state memory is scarce on the
> SH1s: Only 2k)

This why I think a trampoline function is the better way to go.
Ensure that all ports pass a vector number as the first 
argument.  Write a generic set of trampoline code that takes
care of the folks who want the advanced feature of a void * pointer.
It takes (number_vectors * sizeof(void *)) memory to keep up
with those pointers.  I hate to see the minimum memory requirements
creep up yet again.

The trampoline code seems rather generic and the rest is just a matter
of making the the ISR vectoring code always passes the vector
as the first argument.  Then everyone wins.  Users os slow 
CPUs like the SH1 and low end m68k's probably wouldn't use the
trampoline code.  Users on the PowerPC and i386 would probably
use it nearly all the time.

> Ralf

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