Miles Bader schrieb:
Daniel Lohmann <daniel.lohmann@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
Well, it may be not just about speed. On small embedded systems, for
instance, it is often required to be as thrifty as possible with the
stack. Therefore embedded system developers tend to prefer global
(static) over local (auto) variables
You mean on systems with special dedicated stack memory (DSPs?)?
If the stack just uses general memory (as is the case for all the
embedded processors I work with), using "static" for local variables is
going to generally require _more_ memory than using the stack...
Well, not static local variables but global variables instead of local
variables, so it should never take more memory than storing them on the
stack. However, it can have some advantages even if the stack shares
general memory with other data:
1) The linker calculates the required amount of memory for the
.data/.rodata/.bss/... sections during linking. If you are running out of
memory, the linker throws an error so you recognize it immediately.
Calculating the maximum extend of the stack is typically a lot more difficult.
2) If the system supports multiple independent control flows, you might
have to add the memory occupied by local variables to more than one stack.
By using globals this can be avoided - for the price of loosing reentrancy
of that particular code, of course.
3) If function parameters can not be passed in registers but have to be
passed on the stack it might be better to pass them in global variables.
This often reduces code size by leaving out the otherwise required push and
pop operations.
Of course, all this has quite some disadvantages - we all learned at school
that using global variables for everything is evil :-). But it might be the
trick to get your embedded applications into the 512 Bytes of RAM and 2K of
flash that are available...
Daniel
