Re: [avr-gcc-list] stack handling

[Larry Barello]

What is odd is that all the alternative C compilers (ICC,
IAR and CodeVision) use the dual stack mechanism.  As far as
I can tell the code impact is minimal, but, as you noted,
the SRAM impact is large and negative.  Anything that
impacts SRAM on the AVR is a bad thing!

I think it is just history and that the way avr-gcc does it
is derived from the old PDP-ll days when C was developed and
it just happens to be more efficient on the AVR.  I
certainly prefer the gcc way: it is simple to follow and
only one slab of memory needs to be allocated per process.

----- Original Message -----
From: "Flemming Gram Christensen" <address@hidden>
To: <address@hidden>
Sent: Monday, March 12, 2001 7:06 AM
Subject: [avr-gcc-list] stack handling


> Hi.
>
> I'm new to this list, so please excuse me if this question
is "often-asked"
>
> I studied the way avr-gcc and the iar c compiler handles
the stack.
>
> In the documentation for iar it says the iar compiler uses
two stacks:
> one for return addresses (using call and return
instructions) and another
> for data (flushed local variables, structs etc.) accessed
through the Y register.
>
> avr-gcc is only using one stack. When a stack frame is
needed the SP IO register
> is raised using in/out instructions.
>
> What are the pro and cons?
>
> The iar way wastes some memory and special care is needed
to ensure the two stacks
> do not overwrites each other. But frame allocation and
deallocation is efficient.
>
> The gcc way uses more code space, but less memory.
>
> Is there anything written on the codegeneration principles
of avr-gcc?
>
> Regards Flemming