API modification request

[Valette Eric]

Till Straumann wrote:

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

I still do not follow the one instruction argument (or is it C 
instrcutions) at least on PPC/ix86 : pushing table[vector].arg in C is 
more instructions in ASM. The push on Ix86 is already one and the 
computation is probably two and may leed to push a register to store 
intermediate result. On PPC, the computation to get the void* arg is 
worse but you do not need to push the argument (except that r3 may be 
already used).

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

Except that for nested interrupts, you do not need to switch stack and 
need to store for sure only the scratch registers.

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

IRQ5 calls foo5 without argument
foo5()
{
	myHandler5WithVoidPointer(table_entry(5));
}

Not elegant but feasible. You manage the void* table pointer and make 
the trampoline code automagically generated by macros. Sharing irq code 
for diffrent similar devices only changing the void* argument is 
alsofeasible.


> 6) I agree but I don't think the difference in speed is substantial
>    enough.

I will not fight for that. I just want to warn that the API change is 
not only the handler but also the code that connects the IRQ to add the 
void* argument and the global functions that manages the internal IRQ 
tables...


> A) I could (read: would _love_ to) do the change for the PPC
>    architecture.

As far as I'm concerned, I always love to see my code improved provided 
initial credits remains :-) Take care to make code that also work for 
vectors stored in flash for PPC.

> B) Eric (V): would you be willing to work on i386 ;-) ?

I promissed GDB work and did not even start. Besides, I have no hardware 
to test it but as the changes are mostly trivial this is may be not the 
major concern.

BTW can we just discuss the API in more details (e.g by providing the 
irq.h file)


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette at free.fr