Address Space

In embedded systems, the word “address” often sounds as if everyone means the same thing.

In bare-metal code, a pointer may be close to a real SRAM address. RTOS tasks may share one address space. An MCU with an MPU can catch some out-of-bounds accesses, but usually does not provide full address translation. A Linux user process sees virtual addresses, while a DMA device may see a different bus address.

When a program crashes, logs may mention stack overflow, segmentation fault, out of memory, or heap corruption. These are all memory-related, but they are not the same kind of failure.

Stack, heap, globals, text, and mmap regions are not merely “different memory blocks.” They serve different lifetimes, access patterns, and runtime constraints.

A useful first model is: text stores instructions, data stores global state, the stack stores function calls and local execution state, the heap stores dynamically allocated objects, and mmap regions store file mappings, shared memory, large anonymous mappings, and dynamic libraries.

When a program prints a pointer, it looks like it has obtained “a memory address.” Many wrong assumptions start there.

On systems such as Linux, the address seen by a user program is usually not a physical memory address. It is a virtual address. The same 0x400000 in two different processes can point to completely different physical pages. A pointer from one process is not directly meaningful in another process.