Where Programs Live (When Nobody Is Running Them)
Your computer has a lot of software on it — an operating system, a web browser, a word processor, maybe some games or classroom tools. When none of those programs are running, where exactly are they?
They are sitting in secondary memory: the hard drive or solid-state drive (SSD) inside the machine. Secondary memory is built for one thing above all else — keeping data safe when the power is off. It is non-volatile, meaning it holds onto its contents whether the computer is on, off, sleeping, or sitting in a drawer.
Secondary memory is also large and relatively slow. A modern SSD can hold hundreds of gigabytes or several terabytes of programs and files — far more than the CPU could ever work with at one time. That capacity comes at a cost: compared to the rest of the computer, reading from secondary storage takes a noticeable amount of time.
The Problem with RAM
The CPU cannot run a program directly from secondary storage. The CPU works with RAM (Random Access Memory) — the computer's fast, working memory. RAM is where active instructions and data live while a program is running.
RAM is dramatically faster than secondary storage, which is exactly what the CPU needs. But RAM has a critical limitation: it is volatile. The moment the power goes off, everything in RAM disappears. RAM does not hold onto data on its own — it requires a constant supply of electricity to maintain its contents.
This is why you lose unsaved work when the power goes out. The document you were editing existed in RAM. The saved version existed in secondary storage. Without power, RAM forgot everything; secondary storage did not.
The tradeoff in a nutshell: Secondary memory is slow but permanent. RAM is fast but forgetful. Computers need both.
What Happens When You Launch a Program
When you double-click an app or open a browser tab, the operating system does something essential before any code runs: it loads the program from secondary storage into RAM.
This means copying the program's instructions — along with any initial data the program needs — from the slow, permanent drive into the fast, temporary RAM. Once that transfer is complete, the CPU can begin working. Secondary storage steps out of the picture.
From this point forward, everything the CPU does involves RAM. The program's instructions are in RAM. The data the program works with moves in and out of RAM. The CPU never goes back to the hard drive to fetch the next instruction — it works entirely from what is already loaded.
Why This Matters for Understanding the CPU
Once a program is loaded into RAM, the CPU's job becomes a tight, repeating loop: fetch an instruction from RAM, figure out what it means, carry it out, and fetch the next one. That loop — the Fetch-Decode-Execute cycle — is the subject of the next reading.
Notice that secondary storage plays no role in that loop. It does its job once — handing the program over to RAM — and then waits. The CPU and RAM handle everything else together.
This distinction will come up again in Week 3 when we look at how the operating system manages memory, including what happens when a program is too large to fit in RAM all at once. For now, the key idea is simply this: secondary storage is where programs wait; RAM is where programs run.
Connecting this to our metaphor
Think about the movement of information from storage to RAM like a teacher's "Prep Period"
The Metaphor: A program on the Hard Drive is like a curriculum guide sitting in the school library. The teacher can't teach from it while it's in the library.
The Action: During "Prep Period" (Loading), the teacher makes a photocopy of that guide and places it on their desk (RAM). Now that it is on the desk, the teacher can actually start the lesson.