address translation

Suppose your office gives everyone a personal mailbox numbered from 1, and a back-room clerk keeps a chart matching each person's personal box number to the real shelf where their mail actually sits. You hand the clerk your personal number; the clerk looks it up and walks to the true shelf. ADDRESS TRANSLATION is that clerk for memory: the program uses friendly logical addresses starting from 0, and on EVERY access the hardware quietly turns each logical address into the real physical address before touching memory.

Step by step, under paging the translation goes like this. (1) The CPU produces a logical address. (2) The hardware splits it into a page number p and an offset d. (3) It uses p to index the page table (found via the page-table base register), reading the frame number f stored there. (4) It checks the entry's bits — is this page valid? is the access permitted (read, write, execute)? — and traps to the OS if not. (5) It forms the physical address by combining frame f with the unchanged offset d, and that physical address is sent to memory. All of this is done by the hardware Memory Management Unit (MMU) for every single load, store, and instruction fetch — far too often for software to do it. The translation-lookaside buffer caches recent (page -> frame) results so most translations skip the page-table read entirely.

Address translation matters because it is the invisible machinery that gives every process its own clean, isolated address space while they all share one physical memory. It is the enforcement point for memory protection (a forbidden access is caught right here) and the hook on which virtual memory hangs (a missing page is detected here and triggers a page fault). The honest caveat is performance: because it happens on every access, it must be hardware-fast, which is exactly why the TLB and well-designed page-table structures are not luxuries but necessities.