On 09/22/15 04:44, David Chisnall wrote: > On 22 Sep 2015, at 12:39, H.J. Lu via cfe-dev <cfe-...@lists.llvm.org> 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. >
You seem to not understand how x86 works, nor have noted how this is nearly universally supported by various architectures; x86 is the exception here. x86 stores its interrupt state on the stack, not in a register which can be clobbered. Also, a lot of your assertions about "most implementations" only apply to full-scale operating systems. -hpa