API modification request

Till Straumann strauman at SLAC.Stanford.EDU
Mon Feb 3 23:03:10 UTC 2003


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*
3) Ralf: passing an ISR arg is not supported in hardware on all
          CPUs (e.g. SH1), additional lookup needed.
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.

MHO on these:
1) I agree (however, it seems that currently ARM, PPC and x86 are
    the only architectures to implement that API).
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).
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.

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

-- Till




More information about the users mailing list