 RE: 8051 memory during function calls and returns
Per Westermark
Even if the compiler may have implemented a different way of
storing auto variables, it is still trying to match the intentions of
the C language.
So the compmiler/linker tries to reuse the memory used by the
variable. Instead of a stack, it evaluates the full call tree, to see
which other auto variables that will never live at the same time and
that can share the same global memory address as your "VAR".
The end result is still that you must assume that VAR will have an
unknown content whenever you enter "myFunc()".
Note that code memory may not mean exactly what you think. On one
hand, it can mean read-only memory (normally flash). On the other
hand, it can mean the memory region "CODE" accessed by a specific set
of processor instructions. But a processor can mix and match - it can
map RAM into the CODE address space. And it can map flash into the
XDATA address range.
But the CODE address range is read-only. And flash memory is
(basically) read-only. So a variable don't get mapped to any flash
memory or to an address range that only has read-only access
instructions, unless that "variable" happens to be declared "const",
informing the compiler that no changes are allowed. Is it a
"variable", if you can't assign new values to it?
Anyway - because of the limited stack in the 8051, you should
avoid code with recursion or reentrant calls. So don't call the same
function from both main loop and from an interrupt. And thing several
times before deciding on using function pointers - the compiler can't
know which function a function pointer points to at any one point in
the code, so it can't compute perfect call trees to see which scopes
are alive in relation to other variable scopes. And the quality of
that call tree is very important - it controls how well the
compiler+linker can manage to reuse memory between different function
calls.
|