How Computers Work
Opening the Box
Tap an icon and a game appears. Between the tap and the game lies a machine with a small cast of characters, each with one job. Meet the three that matter most: the CPU (the worker), RAM (the desk), and storage (the filing cabinet).
This topic is abstraction in reverse — we are deliberately looking one layer down, at the hardware every program stands on.
The CPU — The Worker
The CPU (Central Processing Unit, or processor) is the component that actually runs programs. A program is a long list of tiny instructions — add these two numbers, copy this value, jump to a different instruction if this one is zero — and the CPU works through them relentlessly, in sequence, exactly as written.
Its rhythm never changes. Forever, it repeats the fetch–decode–execute cycle:
- Fetch the next instruction from memory
- Decode it — work out what operation it is
- Execute it — do the thing
- Repeat
A modern CPU runs this cycle billions of times every second (a 3 GHz processor ticks three billion times a second). Nothing it does is clever; everything it does is fast. Under the hood, "execute" happens in circuits built from logic gates crunching binary — the layers connect all the way down.
RAM — The Desk
The CPU needs its instructions and data within instant reach. That is RAM (Random Access Memory), the computer's fast working memory. Everything currently happening — the running game, the open browser tabs, this very page — is sitting in RAM.
Think of RAM as a desk: whatever you are working on right now is spread out on it, within arm's reach. A bigger desk lets you work on more things at once; when the desk is full, you must keep putting things away and fetching them again, and everything slows down. That is exactly the sluggishness of a computer with too little RAM and twenty tabs open.
RAM has one dramatic weakness: it is volatile. Cut the power and it forgets everything, instantly. Every "unsaved work lost" disaster in history is this one fact.
Storage — The Filing Cabinet
Your files, apps, photos, and the operating system itself must survive being switched off. They live in storage — an SSD (solid-state drive) or hard drive. Storage is non-volatile: no power needed to remember.
So why not just use storage for everything? Speed. Even a fast SSD is many times slower than RAM, and RAM is itself slower than the CPU. There is a hierarchy, a deliberate trade-off at every level:
| Component | Speed | Size | Power off? |
|---|---|---|---|
| CPU (with its tiny internal registers) | fastest | smallest | forgets |
| RAM | very fast | medium (GBs) | forgets |
| Storage (SSD/hard drive) | slower | huge (100s of GBs–TBs) | remembers |
Fast memory is expensive and small; big memory is cheap and slow. Computers use a little of the fast stuff and a lot of the slow stuff, and shuttle data between them.
What Happens When You Launch a Game
Now the whole story fits together:
- You tap the icon — an input
- The operating system finds the game's program file in storage
- The program is copied into RAM (that is what a loading screen is!)
- The CPU starts fetch–decode–execute on the game's instructions
- The game draws to the screen — an output — and reads your taps as input
- When you save your progress, data is written from RAM back to storage, where it will survive shutdown
Every program you have ever run followed this same script.
Why This Helps You
Understanding the machine turns mysteries into diagnoses. Computer slow with many apps open? The desk (RAM) is full. Work vanished in a power cut? It was only in volatile RAM — save early, save often. Loading screens long? Data is trudging from storage into RAM. You are now debugging the hardware layer.
Worked Example — Tracing the Fetch-Decode-Execute Cycle by Hand
The fetch-decode-execute cycle can feel abstract until you trace a tiny, deliberately simplified program through it step by step. Imagine three made-up machine instructions sitting in memory, and a CPU about to run them:
Address 100: LOAD 5 (put the number 5 into a register)
Address 101: ADD 3 (add 3 to the register)
Address 102: STORE 200 (save the register's value to memory address 200)
| Cycle | Fetch (from address) | Decode | Execute | Register value |
|---|---|---|---|---|
| 1 | 100 → "LOAD 5" | "this means: load a value" | put 5 in the register | 5 |
| 2 | 101 → "ADD 3" | "this means: add a value" | add 3 to the register | 8 |
| 3 | 102 → "STORE 200" | "this means: save to memory" | write register to address 200 | 8 (saved) |
Three cycles, three instructions, one register climbing from empty to 5 to 8, then written out to memory. A real CPU does exactly this — just with far more complex instructions, running at billions of cycles per second rather than three cycles on a whiteboard. Every programming language construct you will ever use — a variable assignment, an IF statement, a loop — eventually gets translated down into a long sequence of tiny steps that look exactly like this table, repeated millions of times over.
Key Words
- CPU / processor — executes program instructions via the fetch–decode–execute cycle
- RAM / main memory — fast, volatile working memory holding whatever is running now
- Volatile — loses its contents when power is removed
- Storage — non-volatile, permanent home of files and programs (SSD, hard drive)
- Fetch–decode–execute cycle — the CPU's endless rhythm: get an instruction, understand it, do it