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.
