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