Re: An article I alluded to

[Daniel Lohmann <daniel dot lohmann at informatik dot uni-erlangen dot de>]

Miles Bader schrieb:
> Daniel Lohmann <daniel.lohmann@informatik.uni-erlangen.de> 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