Why Simple Memory Design Is Misleading: The Hidden Complexity of Addressing in Real Mode

Humans prefer direct, simple solutions, but for computers, especially memory management, "simplicity" often hides complexity; the core issue is how a program finds the data it needs, which is called addressing.

Basic Memory Model

Memory can be imagined as a collection of tiny boxes, each storing a 0 or 1; eight boxes form a byte, and every byte has a unique address that allows the CPU to read or write the corresponding bits.

Addressing Concepts

Two common ways to locate a piece of data are illustrated with a locker analogy. The first method gives a fixed locker number (absolute addressing), while the second first selects a region and then an offset inside that region (relative addressing). The images below show these two approaches.

Absolute Addressing Problem

Consider a tiny memory of 8 bytes and a 2‑byte program that contains a jmp 2 instruction. Because the jump target is an absolute address, the program must be loaded at physical address 2; otherwise the jump cannot reach the intended instruction, and the program fails to run. This becomes a serious obstacle when multiple programs must run simultaneously (multitasking), because each would need a pre‑assigned region.

Need for Relocation

To avoid hard‑coding addresses, modern compilers generate code that uses relative addresses. The program’s base address is stored in a segment register, and the offset within the segment is added to obtain the real physical address. This is analogous to using relative file paths ( ./a.c) instead of absolute paths ( /user/xiaofeng/doc/a.c).

/user/xiaofeng/doc/a.c

./a.c

Segment Registers in x86

x86 CPUs provide dedicated registers that hold the base addresses of different memory segments:

CS (Code Segment) – points to the region containing executable instructions.

DS (Data Segment) – points to the region for global variables and static data.

SS (Stack Segment) – points to the region used for the runtime stack.

ES (Extra Segment) – a general‑purpose segment register.

No Memory Protection in Real Mode

In real mode the CPU does not enforce any protection; any program can read or write any physical memory location, including the operating system’s code and data. This makes bugs far more dangerous: a single errant thread can corrupt another thread’s data, and a rogue program can damage the OS itself, requiring a full system reboot.

Characteristics of Real Mode

Early x86 processors could address only 1 MiB of memory. Because registers were 16 bits, a single register could address only 64 KiB; the combination of a 16‑bit selector (segment) and a 16‑bit offset yields a 20‑bit physical address using the formula physical = selector * 16 + offset. The following diagram shows this calculation.

Because there is no virtual‑memory translation or protection checks, memory accesses in real mode are fast, but the lack of isolation makes the system fragile.

Summary

Absolute addresses tie a program to a fixed memory location; using relative addresses with segment registers solves the relocation problem.

Real‑mode memory is limited to 1 MiB and is addressed via selector:offset (16 × selector + offset).

Without memory protection, any program can corrupt any region, which is especially problematic for multitasking operating systems.

Real Mode and Operating Systems

Early operating systems such as DOS and the first versions of Windows ran entirely in real mode. The main drawbacks were the exposure of physical memory and the absence of protection, which led to system instability. Starting with the 80286, x86 introduced protected mode to overcome these issues.

Even modern CPUs still start in real mode after reset to maintain backward compatibility with legacy 16‑bit software; they quickly switch to protected (or long) mode before loading contemporary operating systems.