AVR-Chat

Eric,

> > > > As for a compiler, I find GCC code to be unsuited to
> > > > the AVR
> > >
> > > What about gcc do you find unsuitable for the avr?
> >
> > The fact is unifies the two stacks; the entry/exit code
> for a function
> > is particularly unappealing.
> 
> Can you explain this, perhaps with an example?

Sure.

Take this simple source code:

void g(int *);
void h(int);

void foo(void)
{
  int x;
  g(&x);
  h(x);
}

Gcc generates this with -O3, an abomination in my eyes:

foo:
/* prologue: frame size=2 */
        push r28
        push r29
        in r28,__SP_L__
        in r29,__SP_H__
        sbiw r28,2
        in __tmp_reg__,__SREG__
        cli
        out __SP_H__,r29
        out __SREG__,__tmp_reg__
        out __SP_L__,r28
/* prologue end (size=10) */
        mov r24,r28
        mov r25,r29
        adiw r24,1
        rcall g
        ldd r24,Y+1
        ldd r25,Y+2
        rcall h
/* epilogue: frame size=2 */
        adiw r28,2
        in __tmp_reg__,__SREG__
        cli
        out __SP_H__,r29
        out __SREG__,__tmp_reg__
        out __SP_L__,r28
        pop r29
        pop r28
        ret

== 26 words ==

It uses Y as a frame pointer and combines what should be two separate
stacks (a hardware call stack and a software data stack) into one
unified stack, managing the hardware stack with software and bringing a
lot of overhead with it.  Not only that, it needs to disable interrupts
on function entry and exit, something that's bad form when you need fast
interrupt response.

CrossWorks, on the other hand, does much better:

_foo
        SBIW    R28, 2
        MOVW    R26, R28
        CALL    _g
        LD      R26, Y
        LDD     R27, Y+1
        CALL    _h
        ADIW    R28, 2
        RET

== 8 words ==

Now, which would you think is more efficient from an execution
standpoint, a code density standpoint, and an interrupt latency
standpoint?  No contest.

-- Paul.