Segmentation
Memory divided the way the programmer thinks: code, data, stack and heap become variable-size segments, each with its own base and limit for relocation and protection.
Logical Address
+-----------+--------+
| Segment # | Offset |
+-----------+--------+
|
Segment Table --> base, limit
|
offset < limit ? --no--> Addressing Error
| yes
Base + Offset
|
Physical AddressReal-world analogy: Library sections
| Segment # | Name | Base | Limit |
|---|---|---|---|
| 0 | Code | ||
| 1 | Stack | ||
| 2 | Data | ||
| 3 | Heap |
Check: offset 300 < limit 1100 ✓
Physical address = base 4300 + offset 300 = 4600
The access falls inside segment 2 (Data) and is allowed.
Segment 2 inside physical memory
0 … 8000 bytes of physical memory
| Feature | Paging | Segmentation |
|---|---|---|
| Unit | Fixed-size page | Variable-size segment |
| Address | Page number + offset | Segment number + offset |
| Table | Page table (frame numbers) | Segment table (base + limit) |
| Fragmentation | Internal (last page) | External (holes between segments) |
| Protection check | Valid/invalid bit per page | offset < limit per segment |
| Programmer visibility | Usually invisible — purely physical division | Logical: code, data, stack are real units |
Paging — equal slices
Every block is the same size, so any page fits any frame.
Segmentation — logical slices
Blocks match program structure, so their sizes differ — holes appear.
Segment table: segment 0 → base 1400, limit 1000; segment 2 → base 4300, limit 1100. Translate (0, 1200) and (2, 500).
1. Segmentation suffers mainly from which fragmentation?
2. What does the limit register in a segment entry do?