Memory Mapping Example
| Depends on | Memory Mapping Extra • Memory Management Unit (MMU) |
|---|
Make sure you’re reasonably happy with page table structures before agonising too much over this more realistic example.
This example, this is based on a subset of the 32-bit ARM MMU. ARM Architecture Reference Manual (Section B).
We can have up to 220 4 KiB pages. To keep the first table a reasonable size, we’ll choose a subset of those 20 bits. In this case, take the top 12 bits.
This means the first level table needs 212 entries. If each entry is 32 bits long (i.e. 4 bytes) that occupies 214 bytes (you do the maths!) which we must use.
Remember that all the page tables are stored in the (operating system’s) memory.
Each 32-bit entry includes:
- A validity ‘flag’ indicating whether any page in that space is used: if none is then there is no need for any further information.
- A base address of a second level table. This is 22 bits long.
We’ve used 12 bits from the most significant end to index the first level table, and the 12 least significant bits will be the offset in the page, which leaves 8 bits to index the second level table. 22 + 8 = 30 bits which is enough because the entries are 4 (= 22) bytes long.
Note that the addresses are all formed by concatenating bit fields: no time-consuming adding is needed.
In this example only 20 of the bits in the second-level table have been described (i.e. each page base). Entries are 32 bit long (it’s convenient); some of the 12 bits not used for mapping (in the second-level table) are used for:
- Page protection, such as preventing user access.
- Memory system control, such as allowing data in that page to be cached or buffered during write operations – optimisations that usually have to be prevented when dealing with memory mapped I/O.
and there are some more esoteric functions which need not concern us here.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 9.7, pages 383-384 |
|---|
