- Protection
- Translation
- Pages and Segments
- Page Tables
- Decisions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Pages and Segments
Generally speaking, there are two ways of dividing memory for these translations and protection systems. The 386, coming from a company unfamiliar with the idea of feature bloat, implements both:
- Segmentation. For implementing protection, ideally you want variable-sized blocks, typically called segments. As a programmer, when you want to set the protection for a region of memory, it’s unlikely to be a convenient round size.
- Pages. For translation, fixed-size regions, called pages, are far more convenient. Finding space for a new allocation is easy if the regions are of a fixed size—you just keep a list of the unused regions and pick the next one. This is also very convenient when swapping, because a mapping from virtual memory addresses to on-disk locations can be maintained and searched very cheaply.
Paging generally makes life simpler for operating system and CPU designers, and therefore is much more common than segmentation. Newer x86 chips support segmentation only in 32-bit mode, and most RISC chips don’t support it at all. This is something of a shame, since segmentation can be very useful to programmers if exposed through the language they use, but that option is quite rare.
One additional mechanism was proposed in recent years, known as Mondrian memory protection. This approach separates the protection and translation operations of an MMU. The translation portion is performed via paging (or not at all). Protection is implemented through an efficient mechanism that permits byte-granularity permissions to be defined. Sadly, this technique hasn’t been incorporated into any commercial CPUs (yet).