SV: SV: SV: SV: SV: [Icc-avr] Stack problems

Richard Man richard-lists at imagecraft.com
Fri Aug 22 18:52:58 PDT 2008


Bengt, my apology. Perhaps I take it for grant that "everyone" knows 
how the stack allocation works:

SRAM size >= (size of global data) + (size of the deepest HW stack) + 
(size of deepest SW stack)

size of global data is just the size used by the global variables, 
initialized ones go to the "data" area and uninitialized but 
implicitly initialized to zero ones go to the "bss" area.

The stack usage is tied to the call trees. For example, if you have

main() { foo(); bar(); }

then the two possible call trees are
         main()->foo()
         main()->bar()

and whatever else foo() and bar() are calling.

size of the deepest HW stack is more or less the length of the 
longest call tree chain (multiplies by two bytes).

Generally you would use a generous enough but not overly generous 
number for HW stack. A typical value of 30 to 40 bytes would work for 
most applications.

size of the deepest SW stack is the largest amount of local variable 
(and temporary) usage by the call chains. For a rough estimate, just 
add up all the local variables in your program. This would be a 
little bit pessimistic but it is a starting point. Since the compiler 
may use some temporary space for a function, being pessimistic is good.

Hope this clarifies a bit.

At 04:15 AM 8/22/2008, Bengt Ragnemalm wrote:
>Richard, I am not saying the compiler should be heroic, I am just trying to
>learn how this works.
>
>/

// richard (This email is for mailing lists. To reach me directly, 
please use richard at imagecraft.com) 



More information about the Icc-avr mailing list