Lesson 1: Architecture Refresher

After this lesson, you can whiteboard the entire stack from memory and explain each layer using only analogies. Everything a terminal emulator does — reading input, rendering output, managing memory, communicating between threads — depends on the hardware abstractions covered here.

What is a Computer? #

A computer answers four questions, over and over, billions of times per second:

1. What's the next instruction?
2. What operation does it want?
3. Where are the numbers?
4. Where does the result go?

That's the instruction cycle. Everything — your terminal emulator, the kernel, the GPU driver, the text renderer — is just this loop running at different privilege levels, orchestrated by hardware and software contracts.

Transistors to Logic #

Start at the bottom.

A CMOS inverter is two transistors (one p-type, one n-type) in series. Input high → output low. Input low → output high. One transistor pulls up; the other pulls down. They never conduct simultaneously (no static power draw — the reason CMOS dominates).

From inverters, build a NAND gate. NAND is universal — every boolean function can be constructed from NAND gates alone. AND, OR, NOT, XOR, MUX, full adder, ALU — all NAND.

From adder to ALU #

A 1-bit full adder takes three inputs (A, B, carry-in) and produces two outputs (sum, carry-out):

sum = A ⊕ B ⊕ carry-in
carry-out = (A & B) | (A & carry-in) | (B & carry-in)

Chain 64 of these together and you have a 64-bit adder. Add multiplexers to choose between operations (ADD, SUB, AND, OR, XOR, shifts) and you have an ALU. The operation selector becomes part of the instruction encoding — the opcode.

Registers and the Clock #

A D flip-flop stores one bit. On the clock edge, it captures whatever is on its D input and holds it on Q until the next edge.

N flip-flops sharing a clock = an N-bit register. The clock edge is the heartbeat. Between edges, signals propagate through combinational logic (gates). At the edge, results are captured into registers. This rhythm — propagate, capture, propagate, capture — is synchronous digital design.

The CPU Pipeline #

A classic five-stage pipeline:

flowchart LR
    IF["IF<br/>Instruction Fetch"] --> ID["ID<br/>Instruction Decode"] --> EX["EX<br/>Execute"] --> MEM["MEM<br/>Memory Access"] --> WB["WB<br/>Write Back"]

Each stage takes one cycle. Five instructions can be in flight simultaneously (one per stage). This is why pipelining gives a ~5x speedup — not because any single instruction is faster, but because the factory line is always full.

Hazards #

Three types:

1. Data hazard: Instruction B needs the result of instruction A, but A hasn't reached WB yet. Fix: forwarding — route the ALU result directly to the next instruction's EX stage, bypassing the register file write.
2. Control hazard: A branch instruction changes the PC, but the next instructions are already in the pipeline. Fix: branch prediction — guess the branch direction and speculatively execute. Mispredict → flush the pipeline (discard wrong-path instructions).
3. Structural hazard: Two instructions need the same hardware resource simultaneously (e.g., both want to write registers in the same cycle). Fix: duplicate the resource or stall one instruction.

The Memory Hierarchy #

The gap between CPU speed and memory speed is the defining constraint of computer architecture. The solution: caches.

flowchart LR
    Reg["Register<br/>0 cycles, ~1KB"] --> L1["L1 Cache<br/>4 cycles, 64KB"] --> L2["L2 Cache<br/>12 cycles, 256KB-1MB"] --> L3["L3 Cache<br/>40 cycles, 8-32MB"] --> RAM["RAM<br/>200 cycles, GBs"] --> SSD["SSD<br/>100K cycles"] --> HDD["HDD<br/>millions"]

Why caches work #

Two principles:

1. Temporal locality: if you accessed address X, you'll likely access it again soon (loops, hot variables).
2. Spatial locality: if you accessed address X, you'll likely access nearby addresses soon (arrays, sequential code).

Caches exploit both. Each cache miss fetches a full cache line (64 bytes on x86-64), not just the requested byte. Accessing array[i] pulls in array[i] through array[i+7] for free.

False sharing #

Two threads, two independent variables. If they happen to live on the same 64-byte cache line, each write by one thread invalidates the other thread's cache line. They ping-pong ownership of the line via the MESI protocol, even though they never touch each other's data. Performance drops 10-100x.

// SLOW: both counters on same cache line
struct { int a; int b; } counters;  // a and b share 64 bytes

// FAST: pad to separate cache lines
struct { int a; char _pad[60]; int b; char _pad2[60]; } counters;

Virtual Memory #

Every process sees a private, contiguous address space starting at 0. This is a fiction maintained by hardware and the kernel together.

How it works #

Memory is divided into pages (4KB on x86-64). Each page's virtual address is translated to a physical address via page tables. On x86-64, page tables are 4-level trees:

Virtual address: [16 unused][9 bits L4][9 bits L3][9 bits L2][9 bits L1][12 bits offset]

Each level is a lookup in a table of 512 entries. The entry either points to the next-level table or contains the physical page number. The hardware walks this tree on every memory access.

The TLB (Translation Lookaside Buffer) is a cache for page table entries. A TLB hit avoids the 4-level walk. A TLB miss costs 4 memory accesses. This is why huge pages (2MB, 1GB) exist — one TLB entry covers more memory.

Why fork() is fast #

fork() copies the page tables, not the pages. Both parent and child point to the same physical pages, marked read-only. When either writes, the hardware triggers a page fault. The kernel copies just that one page (copy-on-write), marks both copies writable, and resumes. No bulk copy. Only the pages that actually diverge get duplicated.

mmap #

mmap maps a file (or anonymous memory) into the process address space. Access triggers page faults that read the file lazily. This is how the ELF loader works — the executable's .text and .data segments are mmap'd, not eagerly loaded.

Interrupts and Traps #

Three mechanisms for the CPU to stop what it's doing and run kernel code:

All three use the same mechanism: the CPU looks up a handler address in the interrupt vector table, saves the current state (PC, flags), switches to kernel mode, and jumps to the handler. The handler runs, then iret restores state and returns to user mode.

Spectre/Meltdown #

Both exploit the gap between speculative execution and its side effects. The CPU speculatively executes instructions past a branch or a protection check, then discards the architectural state if the speculation was wrong. But the microarchitectural state (cache contents) is not discarded. A timing side channel can read the cache and leak data across privilege boundaries. This is why kernel page table isolation (KPTI) exists and why array bounds checking has hardware mitigations.

Memory Ordering #

// Core 0                    Core 1
a = 1;                       while (b == 0) {}
b = 1;                       print(a);

You might expect print(a) to always print 1. It doesn't. On real hardware, Core 1 can see b == 1 with a == 0.

Why #

Two hardware features conspire:

1. Store buffer: when Core 0 writes a = 1, the write goes into a local store buffer first, not directly to cache. Core 0 continues immediately. The write becomes visible to other cores only when the store buffer drains to L1 cache. Meanwhile, the b = 1 write might drain first (e.g., b was already in Core 0's cache in Modified state).
2. Cache coherence (MESI): each core has its own L1 cache. The MESI protocol keeps them consistent, but the protocol is asynchronous. Core 1 might see the invalidation for b before the invalidation for a.

The fix: memory barriers #

// Core 0                    Core 1
a = 1;                       r1 = b;
store_release(&b, 1);        load_acquire(&b, &r2);
                              if (r2 == 1) print(a);  // guaranteed: a == 1

Release (store + barrier): all prior stores become visible before this store. Acquire (load + barrier): all subsequent loads see values at least as recent as this load.

Together, release/acquire synchronize: if the acquire sees the release's value, all state before the release is visible after the acquire. This is the C11 memory model's fundamental synchronization primitive.

Projects #

1A: Assembly Anatomy #

Write count_to_100() in C. Compile with gcc -O0 -S. Annotate every assembly line: which pipeline stage does what. Identify ADD, CMP, JLE — map them to the ALU.

1B: Cache Line Detective #

Access a 64MB array with strides 1, 2, 4, 8, ..., 4096. Time each. When stride > 64, every access is a cache miss. Graph the results. Mark where L1/L2/L3 boundaries appear in the access time curve.

1C: False Sharing Lab #

Two threads increment two counters. Version 1: same cache line. Version 2: padded to separate cache lines. Version 1 is ~10x slower. Explain the difference using the MESI protocol.

1D: Page Fault Watcher #

# Linux
perf stat -e page-faults ./program

# macOS
sudo dtrace -n 'vminfo:::maj_fault { @[execname] = count(); }'

Allocate 1GB, touch one byte per 4096. Count page faults. Observe the lazy allocation.

Ghostty Source to Study #

Self-Check #

Can you explain, without notes:

• The 4-question instruction cycle
• Why an adder is just NAND gates
• Why pipelining causes data hazards and how forwarding fixes them
• Why false sharing exists and how padding fixes it
• Why fork() is fast (copy-on-write)
• What happens when you press a key, from interrupt to read() returning
• Why a=1; b=2 on Core 1 can be seen as b=2; a=0 on Core 2