On Tue, Sep 29, 2015 at 2:12 PM, Mike Stump <mikest...@comcast.net> wrote:
> 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.
I added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960#c3
Thanks.
--
H.J.
