segmentation

Think of how you naturally see a program in your head: 'here is the code, here is the stack of pending calls, here is the heap of data I allocate, here is a table of globals.' You do not think of it as one flat ribbon of bytes; you think in meaningful, separately-sized parts. Segmentation is a memory scheme that matches this view: it lets a program's address space be a collection of variable-sized segments, each a logical unit like the code, the stack, or the heap.

Concretely, under segmentation a logical address is not a single number but a pair: a segment number plus an offset within that segment. Each segment can be a different size and is placed independently in physical memory. To translate, the hardware uses the segment number to look up that segment's base and limit in a segment table, checks the offset against the limit (protection), and adds the base (relocation) to get the physical address. So segment 2 (say the stack) might live at one physical base, segment 0 (the code) at another, each with its own length — and the program addresses each by name-and-offset, not by one absolute address.

Why it matters: segmentation gives a programmer-friendly, logical view of memory, and it makes protection and sharing natural — you can mark the code segment read-only and execute-only, or let two processes share one segment (a shared library). Its weakness is that segments are variable-sized, so allocating them in physical memory brings back external fragmentation, exactly as with contiguous allocation. That is why modern systems usually combine segmentation with paging: the logical, named segments give the clean view, while paging each segment removes the external fragmentation.