Hi ,
I am using ARM Cortex M4 . When I compile my code I get "No space in Execution region with .ANY selector matching section .const data .When I decrease the code size I am able to compile the code properly.I think I am overusing the data section which in my controller is 32KB.
I want to know where are all local variables stored in ARM KEIL IDE.Is it stored in Stack dynamically or stored in DATA memory Statically .
Thanks in advance
Regards, Dhanush
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.
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.
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 .
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.
"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!
"So small that it is not realistically usable for automatic variable storage."
Yes, some processors has a stack just intended to handle a couple of levels of return addresses.
Real general-purpose processors on the other hand allows an arbitrary chunk of the RAM to be used as stack - or as multiple stacks in case of use with an OS that allows threads.
The 8051 is better suited for a language like Forth, with software-implemented push and pop operations. Most high-level procedural languages expects arbitrary access to an arbitrary amount of local variables.
I wonder if its designers ever envisaged it being programmed in anything other than assembler...?