C Program Memory Layout in Embedded Systems

[Elctro1]

Hi,
I’ve been learning about the memory layout in C programs for embedded systems, particularly the Text, Data, BSS, Stack, and Heap sections, and how variables are allocated to each.

However, I’m unsure about one key point:
Is this memory layout universal, or does it vary depending on the microcontroller, compiler?

From my understanding, this should be general concept, but the actual placement, sizes, and even the presence of certain sections may differ across platforms. I’d appreciate confirmation if this interpretation is correct

 

[Papabravo]

There may be similarities in the layouts, but each hardware architecture will have unique features. For example, some devices begin execution at a low address while others use a high address. There are even examples of beginning addresses the are in between low and high. The operation of stack pointers may decrease when putting items onto a stack and increase when removing them. It could also be the reverse.

 

[Elctro1]

There may be similarities in the layouts, but each hardware architecture will have unique features. For example, some devices begin execution at a low address while others use a high address. There are even examples of beginning addresses the are in between low and high. The operation of stack pointers may decrease when putting items onto a stack and increase when removing them. It could also be the reverse.

Thanks. I'm trying to understand how compilers assign different variables to memory sections in these architectures:

For 8051 (Harvard): Keil

• Where do these typically get placed?
  • const variables
  • Global variables
  • Static variables
    Does the compiler automatically put them in .text, .data, .bss, stack or heap based on their type/size?

For ARM Cortex-M : GCC
Same questions:

• Where do const, global and static variables usually go?
• Is the assignment to .text, .data, .bss, stack or heap automatic based on variable type?

Is this mainly controlled by the compiler, or do we need to specify locations manually?

 

[rjenkinsgb]

Generally, allocation of memory areas is automatic, unless you specifically override it.
If you are using an assembler, they you may have to define some areas.

None of the compilers I've used in the last few years have needed any manual settings for different data areas, though you can override such as the default heap size etc.

In the ones I use, static and const share the same area as global, the difference is in how the compiler treats them or permits access during compilation.

Local variables are usually on the stack. Heap is memory allocated at run-time, eg. malloc()

.bss is the "data" portion of the executable file, constants before they are copied to RAM variables.
.text is, rather unintuitively, the executable / compiled / machine code section.

 

[Ian Rogers]

It's pretty difficult to determine.. Most here use Pic's and each structure has a different method.

The stack and heap normally reside in the top of the memory. The 8051 has program AND data space at the same address albeit separated. Pic also has ROM and RAM but addressed differently.

Constants are normally in code space. Unless you specify differently.
Then register variables are normally located in the fast access area if available.

Then Data is split into two, Idata and Udata.

Locals are Udata along with any globals you didn't initialize ( these will be linked in if used )
static's and Volatile will be in the Idata "protected" area. ( these will be linked in for definite )

However linkers are compiler specific not structure specific. so without the linker documentation. Christ knows.

If you have the old MPLABC18 they produce a linker script, you can alter this .

Here is a pic18f4620 linker script.

LIBPATH .

FILES c018i.o
FILES clib.lib
FILES p18f4620.lib

CODEPAGE   NAME=page       START=0x0               END=0xFFFF
CODEPAGE   NAME=idlocs     START=0x200000          END=0x200007       PROTECTED
CODEPAGE   NAME=config     START=0x300000          END=0x30000D       PROTECTED
CODEPAGE   NAME=devid      START=0x3FFFFE          END=0x3FFFFF       PROTECTED
CODEPAGE   NAME=eedata     START=0xF00000          END=0xF003FF       PROTECTED

ACCESSBANK NAME=accessram  START=0x0            END=0x7F
DATABANK   NAME=gpr0       START=0x80           END=0xFF
DATABANK   NAME=gpr1       START=0x100          END=0x1FF
DATABANK   NAME=gpr2       START=0x200          END=0x2FF
DATABANK   NAME=gpr3       START=0x300          END=0x3FF
DATABANK   NAME=big           START=0x400          END=0xBFF

DATABANK   NAME=gpr12      START=0xC00          END=0xCFF
DATABANK   NAME=gpr13      START=0xD00          END=0xDFF
DATABANK   NAME=gpr14      START=0xE00          END=0xEFF
DATABANK   NAME=gpr15      START=0xF00          END=0xF7F
ACCESSBANK NAME=accesssfr  START=0xF80          END=0xFFF          PROTECTED

SECTION    NAME=CONFIG     ROM=config
SECTION       NAME=buffer_scn RAM=big   

STACK SIZE=0x100 RAM=gpr14

It was edited by me to to combine 4 databanks for a large data area.. a screen buffer.
Notice the stack is the next to last databank.. the last portion is the fastram

 

[ahsrabrifat]

The conceptual sections (Text, Data, BSS, Stack, Heap) are universal. The physical layout and behavior vary by architecture, compiler, and configuration.