Local variables storage optimization

Hi,

Thanks for your quick reply . I cannot use CONST DATA , in my case the local variables do change .I wish to store the data in data section itself .Is there any method which I can do so.Is there any setting in KEIL for ARM as it had for 8051.In 8051 local variables where grouped together to save space in DATA section . Please let me know anything about local variables.

Regards,
Dhanush

Const data or data. Any initialized variables must get their initial values from somewhere. And that "somewhere" has to reside in the flash, since only the flash content will survive a power loss.

So whenever you add more initialized global variables, you will slowly also increase the amount of flash consumed. The linker + startup code may reduce the amount of flash space needed by storing the initial values in compressed form. But that just scales down on the memory needs. You'll still see the flash space requirements increase as more initialized data gets added.

Is there any method which I can do so.Is there any setting in KEIL for ARM as it had for 8051.In 8051 local variables where grouped together to save space in DATA section .

This is not necessary on an ARM. The locals that would have been overlayed on the 8051 (automatic variables) will go to the stack on an ARM. The result is the same.

Your solution btw is in Per's answer. Try to get the amount of initialized variables reduced as these values are stored in the RO memory.

Hi ,

I think you are deviating from the topic . I wish to know how is "LOCAL VARIABLES" i.e. variables declared inside a function , causing memory overuse problems.I think "LOCAL VARIABLES must be stored in STACK runtime , but I think I am wrong in case of KEIL IDE.

So long story short , I wish to know where are "LOCAL VARIABLES stored in the memory section
And why is it increasing my memory requirement .

Regards,
Dhanush

Local/auto variables are stored on the stack. The stack allocation is typically made in the startup_arch.s

You can reduce static allocations by using dynamic heap allocations, but as Per notes if you want them to contain some specific values, they have to come from somewhere.

If your project exceeds the Eval limit, then you'll need to get a suitably licensed version, or use the GNU/GCC tool chain.

Remember that when you are decreasing your code size, you may also reduce some text strings - maybe part of printouts or data for some display.

A text string is a const data variable in the compilers view. So even if it's used inside a function, the text has to be stored in the flash. Depending on how your code is written, the compiler may be able to use the string directly from flash. Or it may be copied into a RAM-based variable (global or on the stack depending on the used variable scope).

So:

mon_printf("Inside function xx()");

will require the character array "Inside function xx()\0" to be stored in the flash. And the compiler will consider it const data, i.e. you aren't allowed to modify it.

If you instead have:

void my_function() {
    char my_local_array[] = {'a','b','c','d','e','f'};
    ...
}

Then the compiler is free to decide if it will initialize this local variable "my_local_array[]" using explicit procesor instructions, or if the compiler will instead create a secret const data object (it could decide to store this as "text" or as "const data" or whatever it wants to - but it has to originate in flash) allowing the function to start by doing something similar to a memcpy() to initialize that variable.

Hi all,

As per your advice I tried to free some of my code space memory , by taking literal pool strings i.e "strings" into data memory by assigning a char array.Now I am getting "No space in Execution region with .ANY selector matching section .data" or "No space in Execution region with .ANY selector matching section .bss"

Regards,
Dhanush

Hi all ,

I have now found a work around . I have checked the " USE MICRO LIB " check box in

Options for Target -> Target tab.

Please let me know if i ma doing anything wrong .As of now the code is working properly and will let you know if I find any bug in the normal working of code.

Regards,
Dhanush

Your text strings always (!) needs to be stored in the flash. Nothing but what you have in flash survives a power cycle.

Copying the text strings into a RAM variable will not remove the use of flash. It will just add extra code to do the copying. Any copying still requires a source.

Switching to the microlib means you get a bit smaller library so there is a bit more code space available for your own program.

In the end, your program is too large for the processor or for the Keil license.

"The locals that would have been overlayed on the 8051 (automatic variables) will go to the stack on an ARM. The result is the same."

The overlaying used by C51 is only there because the 8051 doesn't have a suitable stack. It achieves at compile-time what the stack does at run-time.

The ARM just uses the Stack - overlaying would be of no benefit.

"The ARM just uses the Stack - overlaying would be of no benefit."

Yes, general-purpose processors are great at doing pointer-indirect addressing with optional offsets.

That means taht they can access local variables on the stack just as fast - and sometimes faster - than they can access a global variable.

A global variable requires the address to that variable.
A local variable can make do with a short offset relative to the "base pointer" of the current stack frame.

Same when accessing function parameters.

The 8051 has extremely bad support for indexed accesses. While it has one or more index registers, they aren't intended for use with offsets. And the 8051 can't even perform indexed accesses for all memory regions. So implementing C on a 8051 is a brutally hard exercise. And the required workarounds should stay on the 8051 and not be mirrored on processors that doesn't needs them.

Not only that, but the 8051 also has an extremely small stack size limit.

So small that it is not realistically usable for automatic variable storage.

So, even if it did have decent indexed access modes, it hasn't got the stack space to put automatic variables there as "normal" targets (like ARM) do.

"the required workarounds should stay on the 8051 and not be mirrored on processors that don't needs them"

Absolutely!