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

API modification request



Am Die, 2003-02-04 um 02.15 schrieb 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.
Neither do it.

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

I was referring to low-level ISRs when talking about "callee". On the
SH1, they don't receive any arguments.

On the caller/interrupt-handler-installation side, we use an array of
pointers to functions and use the IRQ-number as an index into this
array.

> On slow machines who have hardware vectors (i.e. the hardware
> jumps to the ISR directly),
This applies at least to the SH1 and SH2.

> 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
If you are referring to RTEMS-scheduled interrupts, yes. 

But if you are referring to low-level interrupts, you'd have store an
IRQ-argument at a predefined address and somehow have to look up this
address from the inside the ISR (I never had needed to do so, and don't
recall how this could be performed on the SH1)

Now, I fear, this kind of operation could be too expensive (memory
or/and time) for certain tasks if made mandatory.

Ralf