This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Local variable placement on stack or not

I have noted that the C compiler may place some local variables in the .bss section rather then allocate them on the local page frame.

Using CCS DSK 2.21, and the C2000 compiler for the 2407A processor.

If I make a small function, like:

int DoSomething(int a, int b)

{

int c;

  c = a + b;

  return c;

}

then a and b get pushed on the stack by the calling function and c gets allocated to the local page frame and accessed via reg A0 as expected.

---

But, if I allocate many variables inside the function, or maybe floating point variables or longint vars, then I note these get put in the .bss section not the local page frame.

Can someone tell me the algorithm CCS uses to determine which ones get placed in the .bss section, and is there any way I can take control of them and force them to be on the local page frame?

---

There was a time I had a stack overflow issue, and I deliberately placed several variables in the .bss section (had to make them global, but accepted that) to reduce the local stack usage.

But, the compiler created it's own intermediate variables and added them to the .bss section too.

An expression like y = (m * x) + b; for example creates an intermediate variable for the m * x result, and another for the addition of the b. Those intermediate results seems to go into .bss section. Can I make them go on the stack?

Thanks for your help,

Mark.

 

 

  • The compiler allocates "static storage duration" variables (globals, and locals declared "static") to ".bss".  It should not allocate non-static locals or intermediate expressions to ".bss".   It may allocate constant initializers for local variables to ".const".  Do you have a test case which demonstrates this problem?  Be sure to include the options used.  Use the "--keep_asm" option and examine the compiler's assembly output; it should be clear which section each variable is allocated to.