Paging
Virtual memory promised every program a private space and a secret map to the real locations. Paging is HOW that map is actually built — and it's a beautifully simple idea. Chop the program's virtual memory into equal-sized chunks called 'pages', chop the real RAM into equal-sized chunks called 'frames' (the same size), and keep a little lookup list — the 'page table' — that says which page is stored in which frame. To find a real address, the OS just looks up your page in that list and goes to the frame it points to. That's the whole machine.
Pages and frames: equal-sized chunks
Instead of mapping memory one tiny box at a time (way too many boxes to track), paging deals in CHUNKS. It slices the program's virtual memory into equal blocks called PAGES — page 0, page 1, page 2… — each holding a fixed number of boxes. It slices the real RAM into equal blocks of the SAME size called FRAMES — frame 0, frame 1, and so on. A page and a frame are the same size on purpose, because a page is meant to be dropped into a frame like a brick into a slot. So 'page' = a chunk of the program's pretend memory; 'frame' = a chunk of the real memory; same size, made to fit each other. That's the only difference: a page is the make-believe side, a frame is the real side.
The page table: the lookup list
Now we need to remember which page is sitting in which frame. That's the job of the PAGE TABLE: a simple lookup list, one row per page, saying where that page really lives. Like this: page 0 → frame 5, page 1 → frame 2, page 2 → frame 7. Read it like a coat-check ticket stub: hand over 'page 1' and the list tells you 'it's in frame 2'. Every program has its own page table — that IS the secret map from the virtual memory topic, made concrete. The OS fills it in, and special hardware reads it on every memory access to translate page numbers into frame numbers, fast.
Walk one translation, step by step
Let's actually do a lookup, the way the computer does. The program wants something in its virtual PAGE 1. (It thinks page 1 is just the second chunk of its own private memory — it has no idea where that really is.) The OS looks up page 1 in the page table. The table says: page 1 → FRAME 2. So the OS goes to frame 2 in the real RAM — that's where page 1's data actually lives — and reads it. The program gets its data and never learns it was really in frame 2; from its side, it just touched 'page 1'. That tiny look-it-up-and-go step happens on every single memory access, millions of times a second, and it's what makes the whole virtual-memory illusion real.
Why fixed-size chunks? (The clever part.)
Why make every page and frame the exact same size? Because then ANY page fits in ANY free frame — no awkward gaps. Imagine if chunks could be any size. You'd have a 3-box block here, a 7-box block there, holes of odd sizes scattered around. Fitting a new 5-box block means hunting for a hole that's exactly big enough; over time you get lots of little useless gaps that nothing fits into. It's like trying to park cars of every different length along a curb — you end up with wasted slivers everywhere. Fixed-size pages and frames make it like LEGO bricks: every brick is the same, so any brick snaps into any empty stud. A free frame? Drop any page into it, no measuring, no leftover gaps. That simplicity is the entire reason paging chops memory into equal pieces.
Questions you might have
▸What's the difference between a page and a frame?
Same size, opposite sides of the illusion. A PAGE is a chunk of the program's pretend (virtual) memory — what the program thinks it has. A FRAME is a chunk of the real (physical) RAM — where data actually sits. They're made the same size so a page slots neatly into a frame. The page table is the list that records which page is currently living in which frame.
▸Why must the chunks all be the same fixed size?
So any page fits in any free frame, with no wasted gaps. If chunks could be any size, you'd get odd-shaped holes scattered around that new blocks don't fit into. Equal-sized pages and frames are like LEGO bricks: every brick is identical, so any brick snaps into any empty slot. Find a free frame, drop in any page, done — no measuring, no leftover slivers.
▸What exactly is the page table?
It's the lookup list that makes virtual memory work — one row per page, saying which frame that page lives in (page 0 → frame 5, page 1 → frame 2, …). It's the 'secret map' from the virtual memory topic, made real. To translate an address, the OS finds your page's row and reads the frame number. Every program has its own page table, and the OS keeps it filled in.
▸Isn't looking up the table on every access slow?
It would be, so the computer cheats. There's special hardware (and a tiny fast cache of recent lookups called the TLB) that does the page-to-frame translation almost instantly, so you never feel it. The page table is the rulebook; the hardware is the speed-reader that applies it millions of times a second without slowing you down.
Best read after: Virtual memory