API modification request

[Till Straumann]

Joel Sherrill  wrote:
> 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. 

I'm not sure if I understand you guys. If the caller (i.e. the
lowlevel ISR dispatching code) already does the lookup and passes
an argument - why should the callee suffer from this? And as
Joel points out (and my examples for PPC and X86 show) - if you
have to lookup the handler anyways, getting the arg is really
close because you have the intermediate results probably in a
register anyways [and the arg may even be already in a cache, BTW].

On slow machines who have hardware vectors (i.e. the hardware
jumps to the ISR directly), you could e.g. have the isr_install
code assemble a few instructions into where the hardware
vector/jump beams you:

     load_arg_register  #user_arg
     jump_to            user_handler