Memory Mapping Example: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
pc>Yuron No edit summary |
||
Line 4: | Line 4: | ||
Make sure you’re reasonably happy with [[Memory_Mapping_Extra|page table structures]] before agonising too much over this more realistic example. | Make sure you’re reasonably happy with [[Memory_Mapping_Extra|page table structures]] before agonising too much over this more realistic example. | ||
</blockquote> | </blockquote> | ||
This example, this is <em>based on</em> a <em>subset</em> of the 32-bit ARM | This example, this is <em>based on</em> a <em>subset</em> of the 32-bit ARM [[Memory Management Unit (MMU)|MMU]]. [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.architecture.reference/index.html ARM Architecture Reference Manual] (Section B). | ||
[[Memory Management Unit (MMU)|MMU]]. [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.architecture.reference/index.html ARM Architecture Reference Manual] (Section B). | |||
We can have up to 2<sup>20</sup> 4 KiB pages. To keep the first table | We can have up to 2<sup>20</sup> 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. | ||
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 2<sup>12</sup> entries. If | This means the first level table needs 2<sup>12</sup> entries. If each entry is 32 bits long (i.e. 4 bytes) that occupies | ||
each entry is 32 bits long (i.e. 4 bytes) that occupies | |||
2<sup>14</sup> bytes (<em>you</em> do the maths!) which we must use. | 2<sup>14</sup> bytes (<em>you</em> do the maths!) which we must use. | ||
<blockquote> | <blockquote> | ||
Remember that all the page tables are stored in the (operating | Remember that all the page tables are stored in the (operating system’s) memory. | ||
system’s) memory. | |||
</blockquote> | </blockquote> | ||
Each 32-bit entry includes: | Each 32-bit entry includes: | ||
Line 23: | Line 18: | ||
*A base address of a second level table. This is 22 bits long. | *A base address of a second level table. This is 22 bits long. | ||
We’ve used 12 bits from the <em>most</em> significant end to index the first | We’ve used 12 bits from the <em>most</em> significant end to index the first level table, and the 12 <em>least</em> 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 (= 2<sup>2</sup>) bytes long. | ||
level table, and the 12 <em>least</em> 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 (= 2<sup>2</sup>) bytes long. | |||
<blockquote> | <blockquote> | ||
Note that the addresses are all formed by <em>concatenating</em> bit | Note that the addresses are all formed by <em>concatenating</em> bit fields: no time-consuming adding is needed. | ||
fields: no time-consuming adding is needed. | |||
</blockquote> | </blockquote> | ||
[[Image:Two_level.png|link=|alt=Two level page translation]] | [[Image:Two_level.png|link=|alt=Two level page translation]] | ||
Line 37: | Line 29: | ||
*Memory system control, such as allowing data in that page to be [[cache]]d or [[Write_Buffer|buffered during write operations]] – optimisations that usually have to be prevented when dealing with [[Peripheral devices|memory mapped I/O]]. | *Memory system control, such as allowing data in that page to be [[cache]]d or [[Write_Buffer|buffered during write operations]] – optimisations that usually have to be prevented when dealing with [[Peripheral devices|memory mapped I/O]]. | ||
and there are some more esoteric functions which need not concern us | and there are some more esoteric functions which need not concern us here. | ||
here. | |||
---- | ---- | ||
{{BookChapter|9.7|383-384}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Virtual Memory}} | {{Category|Virtual Memory}} | ||
{{Category|Memory}} | {{Category|Memory}} |
Revision as of 14:42, 2 August 2019
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 |
---|