Every general-purpose computer ever built—from room-sized mainframes to smartwatches—consists of three fundamental subsystems working in concert:

1. The Central Processing Unit (CPU) — The brain that executes instructions
2. Memory — The workspace that holds programs and data
3. Input/Output (I/O) — The interface to the external world

This tripartite structure is so fundamental that we take it for granted. Yet understanding precisely what each component does—and crucially, what it cannot do—is essential for anyone who wants to truly comprehend how software executes.

The von Neumann architecture prescribed this organization in 1945, and despite dramatic advances in implementation (transistor counts, clock speeds, parallelism), the logical structure remains remarkably stable. Your laptop is organized the same way as EDVAC was—just faster, smaller, and with more sophisticated optimizations.

The CPU is the active component—the part that actually does things. Memory stores; I/O transfers; but the CPU computes. Every program, no matter how complex, ultimately executes as a sequence of simple CPU operations.

Internal Structure of a CPU

A CPU is not monolithic; it consists of several specialized sub-units:

The Control Unit: The CPU's Conductor

The Control Unit orchestrates all CPU operations. It contains:

• Program Counter (PC): A register holding the memory address of the next instruction to fetch. After each instruction, the PC is updated (usually incremented, but jumps/branches set it explicitly).

• Instruction Register (IR): Holds the currently executing instruction after it's fetched from memory. The instruction remains here while being decoded and executed.

• Instruction Decoder: Interprets the bit pattern in the IR and generates control signals. Each instruction type (ADD, LOAD, JUMP, etc.) produces a unique set of signals that orchestrate the datapath.

• Timing and Control Logic: Generates clock signals and ensures operations occur in the correct sequence. Modern CPUs are synchronous—everything is coordinated by a central clock.

The Datapath: Where Computation Happens

The datapath includes:

• Arithmetic Logic Unit (ALU): The computational engine. Can perform:

  • Arithmetic: addition, subtraction, multiplication, division
  • Logic: AND, OR, XOR, NOT operations
  • Shifts: left shift, right shift, rotate
  • Comparisons: equality, less than, greater than

• Register File: A small, fast set of storage locations (typically 8-64 registers). Registers are vastly faster than main memory (~1 cycle vs ~100+ cycles), so compilers try to keep frequently-used values in registers.

  • General Purpose Registers (GPRs): Programmer-accessible registers for operands and results
  • Stack Pointer (SP): Points to the top of the call stack in memory
  • Status/Flags Register: Contains condition codes (Zero, Negative, Carry, Overflow) that reflect operation results and control conditional branches

Memory in the von Neumann architecture is conceptually simple: a large array of addressable storage locations. Each location holds a fixed unit of data (typically a byte) and is identified by a unique numeric address.

The Memory Abstraction

From the CPU's perspective, memory provides two fundamental operations:

1. Read (Load): Given an address, return the data stored at that location
2. Write (Store): Given an address and data, store the data at that location

That's it—memory is essentially a giant lookup table. But this simplicity hides significant complexity in implementation.

Address Space Organization

The address space—the range of all possible addresses—is logically partitioned for different purposes:

┌──────────────────────────────────────┐  High addresses (e.g., 0xFFFFFFFF)
│              Stack                    │  ← Grows downward
│            (local vars,               │
│             return addrs)             │
├───────────────────────────────────────┤
│                 ↓                     │
│           (unused space)              │
│                 ↑                     │
├───────────────────────────────────────┤
│              Heap                     │  ← Grows upward
│         (dynamic allocation)          │
├───────────────────────────────────────┤
│         Uninitialized Data            │  (.bss segment)
│          (global zeros)               │
├───────────────────────────────────────┤
│          Initialized Data             │  (.data segment)
│       (global variables)              │
├───────────────────────────────────────┤
│             Text/Code                 │  (.text segment)
│     (program instructions)            │
├───────────────────────────────────────┤
│            Reserved                   │  (OS kernel space, memory-mapped I/O)
└──────────────────────────────────────┘  Low addresses (e.g., 0x00000000)

Why This Organization Matters

• Stack grows down, heap grows up: This maximizes the distance before collision. Stack overflow happens when stack pointer enters heap territory.
• Code segment is often read-only: Prevents accidental (or malicious) code modification.
• Separation enables protection: The OS can mark regions with different permissions (read/write/execute).

Endianness: A Subtle but Critical Detail

When a multi-byte value (like a 32-bit integer) is stored in byte-addressable memory, which byte goes first?

Registers deserve special attention because they're where computation actually happens. The ALU cannot operate on memory directly—operands must first be loaded into registers, computation performed, and results stored back.

Types of Registers

Modern CPUs have several categories of registers:

Register-Memory Speed Gap

The performance difference between register access and memory access is dramatic and growing:

This explains why compilers work so hard to keep values in registers and why cache behavior dominates modern performance analysis.

A computer that cannot interact with the external world is useless. I/O is how the system communicates with:

• Human users: Keyboard, mouse, display, speakers, touchscreen
• Persistent storage: Hard drives, SSDs, flash memory
• Networks: Ethernet, WiFi, Bluetooth
• Other devices: Sensors, actuators, printers, cameras, game controllers

From the CPU's perspective, I/O devices are accessed through I/O controllers—specialized hardware that bridges the gap between the CPU's world of addresses and bytes and the device's specific interface.

Two Approaches to I/O

I/O Controller Structure

An I/O controller typically provides several CPU-accessible locations:

I/O Communication Methods

There are three fundamental ways the CPU can communicate with I/O devices:

1. Programmed I/O (Polling)

• CPU explicitly reads/writes device registers
• CPU busy-waits, repeatedly checking status until operation completes
• Simple but wastes CPU cycles
• Suitable for simple, fast devices or when OS isn't available

2. Interrupt-Driven I/O

• CPU initiates operation and continues other work
• Device signals completion via hardware interrupt
• CPU stops current work, runs interrupt handler
• More efficient but adds interrupt handling complexity

3. Direct Memory Access (DMA)

• CPU configures DMA controller with source, destination, size
• DMA controller transfers data directly between device and memory
• CPU is free to execute other code during transfer
• Interrupt signals completion
• Essential for high-bandwidth devices (disk, network, video)

The CPU, memory, and I/O don't operate in isolation—they communicate constantly. This communication occurs over buses: shared electrical pathways that carry signals between components.

The Classic Three-Bus Model

In the original von Neumann conception, three logical buses connect components:

A Memory Read Operation in Detail

Let's trace exactly what happens when the CPU executes LOAD R1, [0x1000]:

1. Address Output (Cycle 1)

   • Control Unit places 0x1000 on the address bus
   • Control bus signals: READ operation, memory (not I/O)

2. Memory Access (Cycles 2-3, or more)

   • Memory controller receives address
   • Row/column decoders activate the correct memory cells
   • Data appears on memory's internal data lines
   • Memory drives data onto the data bus

3. Data Capture (Cycle 4)

   • CPU samples the data bus
   • Control Unit routes data to register R1
   • Read operation completes

Bus Arbitration

Buses are shared resources. When multiple components want to use the bus (e.g., CPU and DMA controller both want memory access), a bus arbiter decides who gets access:

• Priority-based: Different devices have fixed priorities (CPU usually highest for latency-sensitive work, DMA for throughput)
• Round-robin: Fair sharing among requesters
• TDMA (Time Division): Fixed time slots allocated to each device

Bus arbitration is a classic resource management problem—a preview of process scheduling concepts you'll encounter later.

The CPU-Memory-I/O organization directly shapes how operating systems are designed. Each component creates responsibilities for the OS:

CPU Management

The OS must:

• Schedule processes: Decide which process gets CPU time
• Handle interrupts: Respond to hardware events
• Manage processor modes: Switch between user and kernel mode
• Context switch: Save and restore CPU state when switching processes
• Handle exceptions: Respond to CPU-detected errors (divide by zero, page fault)

Memory Management

The OS must:

• Allocate memory: Assign memory regions to processes
• Protect memory: Prevent processes from accessing each other's memory
• Implement virtual memory: Create the illusion of large, private address spaces
• Handle page faults: Load data from disk when accessed
• Optimize for hierarchy: Ensure good cache behavior

I/O Management

The OS must:

• Abstract devices: Present uniform interfaces despite hardware differences
• Buffer and cache: Smooth the speed mismatch between CPU and devices
• Handle interrupts: Service device completion events
• Multiplex access: Let multiple processes share devices safely
• Ensure fairness: Prevent any process from monopolizing I/O

Understanding CPU, memory, and I/O at this level has immediate practical applications:

Performance Debugging

When software is slow, the bottleneck is usually one of these three components:

• CPU-bound: All cores are at 100%, profiler shows compute-heavy functions

  • Solution: Optimize algorithms, parallelize

• Memory-bound: Cache misses are high, memory bandwidth saturated

  • Solution: Improve data locality, reduce working set size

• I/O-bound: CPU is idle, waiting for disk or network

  • Solution: Async I/O, caching, batching, faster storage

Writing Efficient Code

Knowing the component structure helps you write faster code:

1. Minimize memory accesses: Keep working data in cache by improving locality
2. Prefer registers: Use local variables; avoid globals (compilers can register-allocate locals)
3. Batch I/O: Fewer large transfers beat many small ones
4. Avoid polling: Use event-driven I/O (callbacks, async/await, select/poll)
5. Understand alignment: Misaligned accesses may require multiple bus transactions

We've explored the three fundamental components that constitute every von Neumann computer. Let's consolidate:

What's Next:

We've seen what the components are. The next page dives deep into how they communicate—the bus architecture. We'll explore the evolution from simple shared buses to modern point-to-point interconnects, understand bus protocols, and see why bus design fundamentally constrains system performance. This knowledge is essential for understanding why certain OS design decisions exist.