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

Johannes Assenbaum jassenbaum at htp-tel.de
Thu Nov 29 14:25:17 PST 2007


Yes, Albert, local vars in main() may claim for forever-unused stack.

If you are lucky, they only claim for registers, but you cannot rely on.

Best regards,
Johannes


> 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


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


> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.16.10/1159 - Release Date: 29.11.07 11:10




More information about the Icc-avr mailing list