This page assumes nothing. Before you read the parent virtual-memory note, you must be fluent in every symbol it throws at you. We build each one from the ground up, in an order where each rung of the ladder rests on the one below it.
Look at Figure s01 below: RAM is drawn as a straight row of lockers, and the coral one is byte number 4000. Notice the address is nothing more than the label under a locker — hold this picture, because virtual memory's whole job is to secretly swap which real locker a label points to.
Why the topic needs it. Virtual memory is entirely about rewriting these house-numbers. If you don't picture memory as a numbered row of lockers, nothing else lands. "Byte-addressable" (a phrase the parent uses) simply means every locker holds one byte and has its own number — we count in bytes, not in bigger chunks.
Figure s02 plots this explosion: each extra bit doubles the number of nameable things (note the log scale — the bars climb by a constant factor, which is what "doubling" looks like on a log axis). Read off 212: twelve wires already name 4096 distinct things.
The sizes you will meet (memorize the shape, not the digits):
Why the topic needs it
Page sizes, address widths, and page-table sizes are all counts of "how many patterns can n bits make" — which is always 2n.
For example the binary string 1101 means
1⋅23+1⋅22+0⋅21+1⋅20=8+4+0+1=13.
Why the topic needs it. The parent's key move — "slicing the bits" of an address into a page number and an offset — only makes sense if you see an address as a physical row of bits you can cut with scissors.
Because 1 hex digit = 4 bits exactly, so grouping / slicing bits by page boundaries is clean; decimal has no such alignment.
Why the topic needs it. Every address in the worked examples (0x5A3C, 0x12A3C, 0x9004) is hex. If you can flip between hex and 4-bit groups in your head, you can read the offset straight off the low digits.
Together they satisfy the identity that the parent leans on:
a=quotient⌊a/b⌋⋅b+remainder(amodb).
Figure s03 makes this concrete: the number 37 is laid out as three full blocks of 10 (the quotient 3) plus a partial butter-coloured stub of length 7 (the remainder). The quotient answers "which block?" and the remainder answers "how far inside?" — the exact two questions virtual memory asks.
Why the topic needs it
Splitting a virtual address into VPN (quotient) + offset (remainder) is integer division by the page size.
Before the next formula, we must name two things the parent uses constantly.
Now the shortcut. When you divide by 2p (a power of two), quotient and remainder become pure bit-slicing — no arithmetic needed:
Figure s04 shows the cut in action: the same bits of 0x5A3C are drawn as a row, with red scissors sitting at bit p=12. Everything to the right of the scissors (lavender→butter) is the offset (remainder); everything to the left is the page number (quotient).
Why the topic needs it. This is the reason page sizes are powers of two: it turns the (slow) divide-and-remainder into a (free) "cut the bit-row here" operation the hardware does for nothing.
Once we have translated the page number, the hardware must rebuild a full address by gluing the new page part back onto the untouched offset. It does this with two operations — let's define them on their own first, using a plain number x, and only then apply them to addresses.
We now have every ingredient. §7 names the address labels (PA, VPN, PFN, …) and only there do we write the parent's final formula PA=(PFN≪p)∣offset — because it needs those labels to make sense.
Each foundation is a prerequisite for the box it points into. Follow the arrows: powers of two and binary make bit-slicing possible, which makes the VA split possible, which the page table consumes, which shift+OR reassembles into the final translated address.
