API modification request

[Joel Sherrill]

Till Straumann wrote:
> 
> OK, let's recap the discussion:
> 
> Me: I'd like to have the ISR passed a user argument,
>      i.e. not
> 
>         typedef void (*rtems_irq_hdl)(void); /* current */
> 
>      but
> 
>         typedef void (*rtems_irq_hdl)(void *arg); /* proposed */
> 
> All of you (Chris, Joel, Ralf, Eric N. and Eric V.), in
> principle, would agree with such a change.
> 
> There are some concerns:
> 
> 1) Joel: should be present + consistent for all architectures
> 2) Ralf: arg type should be a dedicated / abstract pointer type
>           rather than void*

I think this is easy to take care of.

> 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.  So it is
only 1 logical step away from being able to index into a table 
of pointers.

> 4) EricV:passing an arg is more expensive than an extra instruction
>           (which was my claim [for x86 and PPC]).
> 5) EricV:passing an arg can be achieved with a trampoline fcn using
>           the current API.
> 6) EricV:passing the vector could be a little cheaper than passing
>           an arbitrary argument.

I believe EricV is correct and this is essentially the idea I proposed
in the other email (response to Laurent Guerby).
 
> MHO on these:
> 1) I agree (however, it seems that currently ARM, PPC and x86 are
>     the only architectures to implement that API).

All of the ports know the vector of the interrupt and could pass that
or a pointer to some data.  

It is true that there are differences in the interrupt API on those
3 ports from the rest though.

> 2) OK / no problem.
> 3/4) I claimed that table_entry->hdl(table_entry->arg) is only one
>     extra instruction on x86/PPC. If the hardware gives you just one
>     pointer, there are one more instructions needed. The worst case
>     is hardware jumping directly to some vector table entry. In this
>     case, you'd probably need in the order of 5 instructions.
>     Provided that the MMU/segment hardware doesn't
>     have to be setup also, the extra instructions should still be
>     very few (expecially in relation to the context saving / stack
>     switching efforts).

I think that most of the overhead has been incurred to get a vector
number
in order to know which handler to invoke.  The additional overhead is on
the order of:

  + memory for the void * pointer
  + address offset calculation
  + fetch void * from table
  + arrange it as an argument (might be a push)
  + post ISR argument call frame teardown

Even on the m68k family, you are looking at just a few instructions.

> 5) I can't see how this can be implemented without assembly + in a
>     generic way. IMO, the extra code and space needed outweight the
>     benefits of not having an argument.
> 6) I agree but I don't think the difference in speed is substantial
>     enough.

I think using a trampoline function as described in my previous message
would work fine and add little additional overhead as long as every 
port passes a vector number.

> My conclusion: There seems to be no strong opposition. Let's change
> it NOW, at a time where relatively few architectures need to be changed.
> 
> A) I could (read: would _love_ to) do the change for the PPC
>     architecture.
> B) Eric (V): would you be willing to work on i386 ;-) ?
> C) Who's taking over the ARM (there are few BSPs, as it seems) ?

Back to Joel's main concern.. what about the other ports?  

> -- Till

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