• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 23 subscribers
  • Views 1871 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

8051 Data - Free space, Determining of stack size

Rochus

Hi,

I have been using the 8051 for several weeks. It is not yet clear to me how free space is determined in DATA and how the stack size is determined.

In the SCILABS_STARTUP.A51 file I see that the STACK segment is used to determine the start of the stack, however I can't find the linker file and see how  the STACK segment was defined and how its' address is assigned. I also can't find these settings in project settings.

I also see that static variables in functions are declared in DATA. Can anyone give some pointers or a URL on how free space in DATA is determined ? Is it a combination of 

  • Data already declared in DATA
  • Static variables in functions 
  • How reliant functions would be in using the stack
  • Number of register banks used

Any help would be appreciated.

thanks,

Rochus

Parents
  • 0 in reply to Andy Neil

    Thanks Andy. Yes I meant SILABS.

    Thanks for the URLs.

    I guess the summary is:

    1) From http://www.keil.com/support/docs/250.htm

    The stack typically starts following the last individual variable allocation in internal memory and is free to grow *up* through whatever memory remains. C51 stack usage is minimal.

    2) From http://www.keil.com/support/man/docs/lx51/lx51_overlaying.htm

     The linker analyzes the structure of the program and creates a call tree which it uses to overlay the data segments containing local variables and function arguments. This technique works extremely well and provides the same efficient use of memory as a conventional stack frame. It is sometimes called a compile-time stack since the stack layout is fixed by the compiler and linker. An advantage of the compile-time stack is that arguments and local variables are accessed directly using fixed memory addresses (which is very fast on the 8051). Typical stack-based accesses are indirect and execute more slowly on the 8051.

    So I guess the compile-time stack analysis yields the amount of memory that must be reserved for stack. I am not sure if this is available to the programmer.

    As such how does the programmer know how much he/she can allocate to DATA before it conflicts with the stack requirements, without having the linker give you errors ?

Reply
  • 0 in reply to Andy Neil

    Thanks Andy. Yes I meant SILABS.

    Thanks for the URLs.

    I guess the summary is:

    1) From http://www.keil.com/support/docs/250.htm

    The stack typically starts following the last individual variable allocation in internal memory and is free to grow *up* through whatever memory remains. C51 stack usage is minimal.

    2) From http://www.keil.com/support/man/docs/lx51/lx51_overlaying.htm

     The linker analyzes the structure of the program and creates a call tree which it uses to overlay the data segments containing local variables and function arguments. This technique works extremely well and provides the same efficient use of memory as a conventional stack frame. It is sometimes called a compile-time stack since the stack layout is fixed by the compiler and linker. An advantage of the compile-time stack is that arguments and local variables are accessed directly using fixed memory addresses (which is very fast on the 8051). Typical stack-based accesses are indirect and execute more slowly on the 8051.

    So I guess the compile-time stack analysis yields the amount of memory that must be reserved for stack. I am not sure if this is available to the programmer.

    As such how does the programmer know how much he/she can allocate to DATA before it conflicts with the stack requirements, without having the linker give you errors ?

Children
No data