Computer architecture¶

Exercise information-and-architecture-annex.pdf · PDF

The Von Neumann architecture (1945)¶

In the 1940s, computers like ENIAC (Electronic Numerical Integrator And Computer) filled entire rooms. The creepy part: to give them a new task, engineers had to unplug and rewire the machine by hand — "programming" took days of plugging cables. The program wasn't inside the computer; it was the wiring.

In 1945 the mathematician John von Neumann wrote down a blueprint that killed that problem. It was so good that almost every computer you'll ever touch — your phone, a car's engine computer, a data-center server — is still built exactly like this:

flowchart TB
    subgraph CPU ["CPU — Central Processing Unit (the chef)"]
        direction LR
        CU["<b>Control Unit</b><br>the head: reads the recipe,<br>orders the other parts"]
        ALU["<b>ALU</b><br>the hands: does the<br>math and the logic"]
        REG["<b>Registers</b><br>tiny ultra-fast slots for<br>the values used right now"]
        CU <--> ALU
        CU <--> REG
        ALU <--> REG
    end

    subgraph MEM ["Memory — RAM (the countertop)"]
        direction LR
        PROG["<b>Program</b><br>the recipe:<br>instructions, as bits"]
        DATA["<b>Data</b><br>the ingredients:<br>numbers, text... as bits"]
    end

    subgraph IO ["I/O devices (doors to the world)"]
        direction LR
        IN["<b>Input</b><br>keyboard, mouse, mic,<br>network, sensors..."]
        OUT["<b>Output</b><br>screen, speakers,<br>network, motors..."]
    end

    BUS(["<b>BUS</b><br>the shared corridor:<br>everything travels through here"])

    CPU <-->|"fetch instructions,<br>read and write data"| BUS
    MEM <-->|"program and data"| BUS
    BUS <-->|"information in,<br>information out"| IO

Four ingredients, one idea holding it together:

1. The stored-program concept — the revolution¶

The program and its data live together in the same memory, and both are stored as bits — the program is just data that the CPU treats as instructions.

Think about how huge that is:

• Before: new task = days of rewiring.
• After: new task = load new instructions into memory. Takes seconds.
• This is why you can install an app today and run it tomorrow, and why a virus (a program!) can end up in the same memory as your photos. One memory, one format: bits.

2. The CPU — the chef¶

The Central Processing Unit is the part that actually runs the program. It is not one thing; inside it live three workers:

Registers matter more than they look. The ALU can only work on values that are right there, so the CU constantly shuffles data: memory → register, register → ALU, result → register, register → memory. Fast shuffling is everything.

3. Memory — where the recipe and the ingredients live¶

The program and its data sit in the same memory as plain bits. There are two main kinds, and you need both:

• RAM (Random Access Memory) — the workspace. Whatever is running right now lives here. "Random access" means you can jump to any position instantly — like picking any song from a playlist, not fast-forwarding a cassette. Volatile: cut the power and everything vanishes.
• Disk (SSD/HDD) — the pantry. Huge, slower, non-volatile: your files survive power cuts.

Why not skip RAM and run programs straight from the disk? Speed. The disk is thousands of times slower — the CPU would spend its life waiting. RAM is the fast staging area; the disk is the archive behind it.

4. I/O — the doors to the outside world¶

A computer that talks to nobody is a brick. Input devices bring information in (keyboard, mouse, microphone, network card, sensors); output devices send results out (screen, speakers, motors). Some doors swing both ways — a network card or a touchscreen is input and output.

5. The bus — the corridor connecting every room¶

All the parts above are connected by the bus: a shared set of wires. Roughly three kinds of traffic travel on it:

• Data — what is being moved (a number, a letter, an instruction).
• Address — where it goes (every byte in memory has a number, like a street address).
• Control — who may talk and in which direction (reading or writing?).

Everything rides the same corridor — which is brilliant for simplicity, and also its weak spot:

The Harvard architecture¶

Around the same time, the Harvard Mark I (1944) took a different path: it read its instructions from a punched paper tape and kept its data somewhere else. That idea is the Harvard architecture: program and data live in separate memories, each with its own bus.

flowchart LR
    PM["<b>Program memory</b><br>instructions only"] <-->|"instruction bus"| CPU["<b>CPU</b>"]
    CPU <-->|"data bus"| DM["<b>Data memory</b><br>data only"]

• Two corridors: the CPU can fetch the next instruction and read data at the same time — no single bottleneck.
• Safer: data can never be executed by accident, and a program cannot overwrite itself.
• Rigid: the split is fixed. Free space in data memory cannot be used for a bigger program, and vice versa.
• More hardware: two memories, two buses, more wires.

You still find pure Harvard in microcontrollers and DSPs (digital signal processors). The Arduino Uno's chip keeps the program in 32 KB of flash and the data in 2 KB of RAM — two separate memories.

The modified Harvard architecture (Your current CPU)¶

Neither of them, and both. Every current CPU — Intel, AMD, Apple M, the one in your phone — uses a modified Harvard architecture, a hybrid:

• Outside the chip, it is Von Neumann: one RAM, one address space, programs and data mixed as bits. Installing an app is still just copying bits into memory.
• Inside the chip, it is Harvard: the fastest cache level (L1) is split in two — L1i for instructions and L1d for data — each with its own path, so fetching and reading data don't wait for each other.
• It borrows Harvard's safety: memory pages can be marked as non-executable (the NX bit), so the CPU refuses to run bytes that are supposed to be data. That blocks a whole family of attacks.

Try it on Linux: lscpu | grep L1 shows the two halves of your L1 cache (L1d and L1i).

The heartbeat: fetch → decode → execute¶

So what does the CPU do all day? One loop, forever:

flowchart LR
    A["<b>1 · FETCH</b><br>get the next instruction<br>from RAM"] --> B["<b>2 · DECODE</b><br>understand what<br>it is asking for"] --> C["<b>3 · EXECUTE</b><br>actually do it:<br>add, compare, jump..."]
    C --> A

1. Fetch — the Control Unit asks RAM for the next instruction (it keeps a pointer saying where the next one is).
2. Decode — the instruction is just bits; the CU translates them into a concrete action: "add these two numbers".
3. Execute — the action happens (usually in the ALU), the result is stored, and the pointer moves to the next instruction.

A "3 GHz" CPU repeats this loop about 3 billion times per second. Every app you use — games, browsers, WhatsApp — is ultimately this tiny loop, running very, very fast.

Watch one instruction go through the machine¶

1. LOAD  5        ← grab the number 5 from RAM
2. ADD   3        ← add 3 to it
3. STORE result   ← write the answer back to RAM
4. PRINT result   ← send it out to the screen

Follow line 2 (ADD 3) through the diagram above:

1. Fetch: CU asks RAM, over the bus, for instruction #2. RAM sends the bits; the CU parks them in a register.
2. Decode: the CU recognizes "this is an ADD". It arranges for the value in the register (5) to meet the value 3.
3. Execute: the ALU computes 5 + 3 = 8 and leaves the result in a register. The loop restarts for instruction #3, which ships the 8 back to RAM over the bus.

A program that adds 5 + 3 might look like this. Press Next to run it one step at a time and watch which part of the machine is working:

1. LOAD  5        ← grab the number 5 from RAM
2. ADD   3        ← add 3 to it
3. STORE result   ← write the answer back to RAM
4. PRINT result   ← send it out to the screen

Four instructions in, and the machine has already done fetch–decode–execute four times. Now multiply by three billion per second — that's your phone.

RAM vs. disk: aren't they both "memory"?¶

Yes — but they play completely different roles:

Key takeaways¶

• Before 1945, "programming" a computer like ENIAC meant rewiring it by hand.
• The Von Neumann architecture (1945) is the blueprint almost every machine still uses: CPU + memory + I/O, connected by a bus.
• The revolution was the stored-program concept: the program lives in the same memory as the data, both as bits. No more rewiring.
• Inside the CPU: Control Unit (decides), ALU (computes), registers (hold what's in use right now).
• RAM = fast, small, volatile workspace. Disk = slow, huge, permanent archive. You need both.
• The CPU's whole life is fetch → decode → execute, billions of times per second.
• One shared bus means the CPU waits for memory: the Von Neumann bottleneck.
• Harvard keeps program and data in separate memories; current CPUs use a modified Harvard: one RAM outside, split L1 cache inside.

Quick check¶