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