On Sep 29, 2015, at 1:16 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Tue, Sep 29, 2015 at 11:49 AM, Mike Stump <mikest...@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.