Hello,
I was hoping someone could tell me how the memory works during functions call out of main.
In regular C and C++, after functions return, the memory is free again.
How does it work in the 8051 using C?
For example:
void myFunc() { int VAR = 1; }
When the function gets called does VAR use data memory or code memory? When it returns, is the memory that VAR used, free to be used again?
Thanks.
"In regular C and C++, after functions return, the memory is free again"
In "regular" C, automatic variables are usually allocated on the stack. The 8051 doesn't have any stack worth speaking of, so another approach is needed - search the Keil site for "Overlaying"...
See also:
http://www.keil.com/support/man/docs/c51/c51_le_funcparmsstack.htm
http://www.keil.com/support/man/docs/c51/c51_le_reentrantfuncs.htm
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.
Thanks for the in depth reply.
To make sure I understand, the compiler will try to allocate a certain amount of memory to be reused/shared by functions? In that case, does that mean splitting your code into more functions with local variables can be better for managing DATA and XDATA memory than using global variables, considering the functions are not recursive or nested?
In that case, does that mean splitting your code into more functions with local variables can be better for managing DATA and XDATA memory than using global variables, considering the functions are not recursive or nested?
Not really. More functions actually increase the amount of automatic storage needed (for all those local things you would have to pass from one such function to the other).
In that case, does that mean splitting your code into more functions with local variables can be better for managing DATA and XDATA memory than using global variables and the only valid answer is: "that depends".
Erik