Computer architecture is the layer beneath every programming language, operating system, and framework: the physical arrangement of processors, memory, and buses that turns a stored sequence of bits into a running program. It matters because performance, correctness, and even security bugs (timing side channels, integer overflow, misaligned reads) often trace back to decisions made at this level rather than in application code. The key mental model to hold onto while reading these tables is that almost every trick modern CPUs use is a way to hide latency — caches hide slow RAM, pipelining hides slow logic, branch prediction hides slow decisions, and multicore hides the end of single-thread speed gains — so once you can name which latency a technique is hiding, its purpose becomes obvious.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 105 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Foundational Architecture Models
Before anything else, a CPU has to agree on where instructions and data live and how it walks through them one at a time; these models are the blueprint every later table builds on.
| Model | Example | Description |
|---|---|---|
PC → fetch instr → decode → execute → store result | Instructions and data share one memory space and one set of buses, so the CPU only fetches one word at a time. | |
IR ← Mem[PC]; PC += 4; decode(IR); execute() | • Fetch: control unit loads the instruction addressed by the program counter into the instruction register • Decode: opcode and operand bits are interpreted • Execute: the ALU or another unit performs the operation, then the cycle repeats | |
CPU = control unit + processing unit (ALU + registers) | The control unit drives instruction execution while the processing unit performs the actual arithmetic/logic work. |