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

[David Chisnall]

On 21 Sep 2015, at 21:45, H.J. Lu via cfe-dev  wrote:
> 
> 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.  I
> want to keep the number of new intrinsics to minimum without sacrificing
> handler performance. I leave faking error code in interrupt handler to
> the programmer.

The assembly stubs have to come from somewhere.  You either put them in an 
assembly file (most people doing embedded x86 stuff steal the ones from 
NetBSD), or you put them in the compiler where they can be inlined.  In terms 
of user interface, there’s not much difference in complexity.  Having written 
this kind of code in the past, I can honestly say that using the assembly stubs 
was the least difficult part of getting them right.  In terms of compiler 
complexity, there’s a big difference: in one case the compiler contains 
nothing, in the other it contains something special for a single use case.  In 
terms of performance, the compiler version has the potential to be faster, but 
if we’re going to pay for the complexity then I think that we’d need to see 
some strong evidence that someone else is getting a noticeable benefit.

David

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

[David Chisnall]

On 22 Sep 2015, at 12:39, H.J. Lu via cfe-dev  wrote:
> 
> The center piece of my proposal is not to change how parameters
> are passed in compiler.  As for user experience, the feedbacks on
> my proposal from our users are very positive.

Implementing the intrinsics for getting the current interrupt requires a lot of 
support code for it to actually be useful.  For it to be useful, you are 
requiring all of the C code to be run with interrupts disabled (and even that 
doesn’t work if you get a NMI in the middle).  Most implementations use a small 
amount of assembly to capture the interrupt cause and the register state on 
entry to the handler, then reenable interrupts while the C code runs.  This 
means that any interrupts (e.g. page faults, illegal instruction traps, 
whatever) that happen while the C code is running do not mask the values.  
Accessing these values from *existing* C code is simply a matter of loading a 
field from a structure.

I’m really unconvinced by something that something with such a narrow use case 
(and one that encourages writing bad code) belongs in the compiler.

David

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

[David Chisnall]

On 22 Sep 2015, at 12:47, H.J. Lu  wrote:
> 
> since __builtin_exception_error () is the same as
> __builtin_return_address (0) and __builtin_interrupt_data () is
> address of __builtin_exception_error () + size of register.

Except that they’re *not*.  __builtin_return_address(0) is guaranteed to be the 
same for the duration of the function.  __builtin_exception_error() needs to 
either:

1) Fetch the values early with interrupts disabled, store them in a well-known 
location, and load them from this place when the intrinsic is called, or

2) Force any function that calls the intrinsic (and wants a meaningful result) 
to run with interrupts disabled, which is something that the compiler can’t 
verify without knowing the full chain of code from the interrupt handler to the 
current point (and therefore prone to error).

It is trivial to write a little bit of inline assembly that reads these values 
from the CPU and expose that for C code.  There is a good reason why no one 
does this.

Without a better programmer model, you are not simplifying things, you are just 
providing more ways for introducing errors.

David