[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] stack handling

From: Larry Barello
Subject: Re: [avr-gcc-list] stack handling
Date: Mon, 12 Mar 2001 08:19:39 -0800

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]