Re: [PATCH] x86 interrupt attribute

[Mike Stump <mikestump at comcast dot net>]

On Sep 29, 2015, at 1:16 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Sep 29, 2015 at 11:49 AM, Mike Stump <mikestump@comcast.net> wrote:
>> To be feature complete, it would be nice to have two styles of interrupt functions, one that returns with iret, and one that returns with ret.  The point is that the user might want to call functions from a interrupt handler and not save and restore all call clobbered registers.  By allowing a ret style interrupt handler, calls to a ret style interrupt routine can avoid saving and restoring all call clobbered registers.
> 
> Do you have a testcase for this?  I think the current implementation
> covers most use cases.

When I wrote my interrupt support for my cpu, I ran these through the code generator…  I have many registers, and noticed saving and restoring them all just because two interrupt handlers used the same routine was silly.  Test case is trivial:

interrupt void foo2() {
  bar();
}

interrupt void foo1() {
  bar();
}

if more than 1-2 registers are saved, then likely it is saving all call used registers.  Saving all means that one cannot use functions to compose semantics and attain performance.  Performance of ISR routines I think is useful to shoot for, given that it is easy enough to attain, I don’t see the harm in doing that.  Even if in the first implementation you don’t bother with performance, if you spec the other function, the user code need never change; and when performance does matter, it is then a mere matter of enhancing the code gen to do the right thing.  It is pretty easy to get most of the benefit without much work.  i call the main interrupt function interrupt, and the recursive (ret style), I call interruptr.  The r is for recursive.