Keil Logo Arm Logo

Discussion Forum

8051 memory during function calls and returns

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Read-Only
Author
john bool
Posted
23-Jun-2012 05:21 GMT
Toolset
C51
New! 8051 memory during function calls and returns

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.

Read-Only
Author
Andrew Neil
Posted
23-Jun-2012 09:14 GMT
Toolset
C51
New! RE: 8051 memory during function calls and returns

"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

Read-Only
Author
Per Westermark
Posted
23-Jun-2012 12:32 GMT
Toolset
C51
New! RE: 8051 memory during function calls and returns

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.

Read-Only
Author
john bool
Posted
27-Jun-2012 20:46 GMT
Toolset
C51
New! RE: 8051 memory during function calls and returns

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?

Read-Only
Author
Hans-Bernhard Broeker
Posted
28-Jun-2012 18:24 GMT
Toolset
C51
New! RE: 8051 memory during function calls and returns

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).

Read-Only
Author
erik malund
Posted
28-Jun-2012 20:18 GMT
Toolset
C51
New! and the only valid answer is

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

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Keil logo

Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.