[Icc-avr] Variables declared in main() and the stack

Albert vanVeen Albert.vanVeen at pertronic.co.nz
Thu Nov 29 13:26:35 PST 2007


How do you solve Fibernacci without recursion?

But Kevin set me wondering about vars 'local' in main(), usually only
used for initial setups; will they then remain on the stack, forever
unused? As I've never run out of memeory, I've never worried about these
things.

Albert.

 

-----Original Message-----
From: icc-avr-bounces at imagecraft.com
[mailto:icc-avr-bounces at imagecraft.com] On Behalf Of David Brown
Sent: Friday, November 30, 2007 09:52 AM
To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need
tosubscribe to icc-announce if you are a member of this.
Subject: Re: [Icc-avr] Variables declared in main() and the stack

Kevin Davis wrote:
> David,
> 
> Thanks for the good info ... wasn't aware of the register/efficiency 
> issue.
> 
> Regarding your statement on the (lack of a) difference between 
> variables on the stack or main ram, I assume you mean then that the 
> only thing you can control with a compiler option (unless you're using

> a custom config) is the size of the hardware stack containing function

> return addresses, so whether the variables are put on the bottom or 
> top (software stack below the hardware stack) of the ram makes
essentially no difference.
> 

Pretty much correct.

> And, I guess what amounts to the same thing, unless you have a heavily

> recursive program, a stack overflow is primarily caused by the 
> software stack encroaching on the heap.
> 

A program for an AVR should not be using recursion (at least, not until
you are answering questions like these instead of asking them!).  Also,
a program for the AVR should not be using the heap (again, unless you
are an expert) - avoid using dynamic memory.

mvh.,

David


> Kevin
> 
> Kevin Davis
> All Traffic Solutions
> -----Original Message-----
> From: icc-avr-bounces at imagecraft.com
> [mailto:icc-avr-bounces at imagecraft.com] On Behalf Of David Brown
> Sent: Wednesday, November 28, 2007 4:32 PM
> To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need 
> tosubscribe to icc-announce if you are a member of this.
> Subject: Re: [Icc-avr] Variables declared in main() and the stack
> 
> Kevin Davis wrote:
>> I'm learning more about pointers and their relation to the heap and 
>> stack and was wondering:
>>
>> Does it make sense (if scope is not an issue) to make variables that 
>> will only be used in main() global rather than use up stack space 
>> with
> them?
>>  
> 
> In a word, no.  On a target like the AVR, it is *always* more 
> efficient to use local variables rather than global ones.  For the 
> most part, they
> 
> exist only in registers - only if you have lots of them, or if they 
> are aggregates (arrays or structs), do they spill out onto the stack.

> And even if they are allocated on the stack, there is no difference 
> between taking up memory on the stack, and taking up memory in the
main ram.
> 
>> Just curious as to any rules-of-thumb with regards to this (if there
> are
>> any). If this question makes no sense let me know as well but from
> what
>> I've learned the variables declared in main() are put on the stack 
>> and
> 
>> would remain there for the program's duration.
>>
> 
> Local variables in a function do not necessarily exist throughout the 
> lifetime of the function.  They exist *theoretically* throughout their

> scope - but the scope can be any block within a function.  So if you 
> have variables that are only used for part of a function, you can put 
> them inside a block (within a {} pair) for efficiency.  The compiler 
> can
> 
> do this sort of lifetime analysis itself - it does not need to 
> allocate a variable before it is actually used, and can remove it (and

> re-use its
> 
> register or stack space) as soon as it is finished with.
> 

_______________________________________________
Icc-avr mailing list
Icc-avr at imagecraft.com
http://dragonsgate.net/mailman/listinfo/icc-avr

Scanned by Bizo Email Filter




More information about the Icc-avr mailing list