[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
API modification request
- Date: Mon, 03 Feb 2003 17:15:33 -0800
- From: strauman at SLAC.Stanford.EDU (Till Straumann)
- Subject: API modification request
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
>>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
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: