Memory Mapping Example: Difference between revisions

From COMP15212 Wiki
gravatar Yuron [userbureaucratinterface-adminsysopPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+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 ExtraMemory 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.

Two level page translation

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:

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