[cfe-dev] RFC: Support x86 interrupt and exception handlers

[Joachim Durchholz via cfe-dev]

>>> The main purpose of x86 interrupt attribute is to allow
>>> programmers to write x86 interrupt/exception handlers in C
>>> WITHOUT assembly stubs to avoid extra branch from assembly stubs
>>> to C functions.
>>
>> Let's take just this statement. Are you sure that the call/ret
>> pair for such a stub has *any* significant impact on the interrupt
>> latency? I'm quite doubtful of that. That's completely ignoring the
>> fact that raw interrupt or exception latency is generally not an
>> issue.
>
> I agree that this is a highly-relevant question. Demonstrating the
> benefit here is important. I can certainly imagine that it might be
> the case that on embedded systems the latency here is more important.
> The other thing is that it might matter a lot more for syscall/trap
> overhead than for actual externally-sourced interrupts.

Embedded systems are mostly ARM these days, so embedded is not going to 
give much traction to your work.
Maybe Atoms are used there; Intel designed them to be useful for 
embedded, I just don't know whether that worked out.

I'm a bit sceptical that the stub matters much. Most of the overhead in 
interrupts and syscalls/traps is the context switch. On the '386, that 
was dozens (hundreds?) of bytes pushed to the stack. I don't know what 
later models do (my assembly days are long gone), but given that one of 
the major influences on Linux' kernel API design is avoiding context 
switches, I guess things didn't get better.
Talking about Linux, you might want to head over to these folks and see 
what they do about stubs and whether they use gcc options to eliminate 
them where possible. Linux folks are very performance-conscious, if even 
they don't care about the stubs, then stubs are likely irrelevant, or at 
least much less important than the maintenance burden for stub elimination.

Just my 2 cents from the sideline, back to lurking on backend topics :-)

Regards,
Jo