Re: [avr-gcc-list] SIGNAL and INTERRUPT overhead

[Benjamin Titzer]

> Hi,
>
> On Sun, 21 Aug 2005 03:04:02 +0530, Nigel Winterbottom
> <address@hidden> wrote:
> > -----Original Message-----
> > From:James A.R. Koehler
> >
> > If the consensus is that we need to be protected against ourselves by
> > having all the existing prolog in the two existing interrupt service
> > methods, perhaps the solution is to have a third category of interrupt
> > service routine in which nothing is pushed onto the stack and the
> > programmer takes full responsibility for making sure the machine is
> > returned to the same state it was before the interrupt.
> >
> >     Jim
> > ----------------------
> >
> > Actually this already exists in the form of applying an attribute to the
> > SIGNAL or INTERRUPT name. I use it in my code as the example below shows.
>
> > Nigel
>
> --------------------------
> What's required is a peephole optimiser that detects in the assembly
> output the registers used in the function,  or the presence of
> instructions modifying the flags etc and deletes unnecessary matching
> push/pops.
>
> Another peephole optimisation is if a function ends like:
>
>               rcall   label
>               ret
>

This is called tail-call elimination and has been known since the days of
Lisp. Usually this optimization is omitted because it makes it harder to
debug code and doesn't seem to be particularly popular with those
writing compilers for procedural languages.

> It could be replaced with a jump to label (except if it's reti instead of
> ret). This will make the code faster, as extra push/pop of the PC is
> avoided.
>
> Both the above is implemented in SDCC (sdcc.sourceforge.net) a freeware C
> compiler for MCS51 family, which I also use. Can these optimisations be
> implemented a AVR-Gcc?
>

Sounds to me like the design of GCC and the constraints of a particular
calling convention do not allow it to do something smart here. I think the
solution that would satisfy most everyone involved would be for the
compiler to generate code that only saves the state of registers that it
uses (and overwrites) and then restore them upon exit. This is a simple
use-def analysis on the registers and would be simple enough to implement.
It could be integrated as part of the register allocation phase. My guess
is that the prolog code is generated in one place in the compiler and the
functions body in some other place, and that the prolog generator
basically outputs a template of code that saves all the registers,
regardless of what the body does. The best solution would be to combine
these into one smarter code generator.

-B
> --Thanks,
>
> Royce.
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>