Editing Memory management unit (section)

==Examples==
Most modern systems divide memory into pages that are {{nowrap|4–64 [[Kilobyte|KB]]}} in size, often with the capability to use so-called huge pages of {{nowrap|2 [[Megabyte|MB]]}} or {{nowrap|1 GB}} in size (often both variants are possible).  Page translations are cached in a [[translation lookaside buffer]] (TLB).  Some systems, mainly older [[RISC]] designs, [[Trap (computing)|trap]] into the OS when a page translation is not found in the TLB.  Most systems use a hardware-based tree walker.  Most systems allow the MMU to be disabled, but some disable the MMU when trapping into OS code.

=== IBM System/360 Model 67, IBM System/370, and successors ===
The [[IBM System/360 Model 67]], which was introduced August, 1965, included an MMU called a dynamic address translation (DAT) box.<ref>{{cite web|url=http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html |archive-url=https://web.archive.org/web/20050116150036/http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS360.html |url-status=dead |archive-date=January 16, 2005 |title=IBM Archives: System/360 Dates and characteristics |website=03.ibm.com |date=23 January 2003 |access-date=2017-05-03}}</ref><ref name=IBM-S360-67-FuncChar>{{cite web|url=http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/GA27-2719-2_360-67_funcChar.pdf|title=IBM System/360 Model 67 Functional Characteristics, Third Edition|id=GA27-2719-2|date=February 1972|access-date=October 29, 2021}}</ref>  It has the unusual feature of storing accessed and dirty bits outside of the page table (along with the four bit [[Memory_protection#Protection_keys|protection key]] for all S/360 processors).  They refer to physical memory rather than virtual memory, and are accessed by special-purpose instructions.<ref name=IBM-S360-67-FuncChar/>  This reduces overhead for the OS, which would otherwise need to propagate accessed and dirty bits from the page tables to a more physically oriented data structure.  This makes [[OS-level virtualization]], later called [[paravirtualization]], easier.

Starting in August, 1972, the [[IBM System/370]] has a similar MMU, although it initially supported only a 24-bit virtual address space rather than the 32-bit virtual address space of the System/360 Model 67.  It also stores the accessed and dirty bits outside the page table.  In early 1983, the System/370-XA architecture expanded the virtual address space to 31 bits, and in 2000, the [[64-bit]] [[z/Architecture]] was introduced, with the address space expanded to 64 bits; those continue to store the accessed and dirty bits outside the page table.

=== VAX ===
[[VAX]] pages are 512 bytes,<ref name="vax-ref-manual">{{Cite book |url=http://bitsavers.org/pdf/dec/vax/archSpec/EY-3459E-DP_VAX_Architecture_Reference_Manual_1987.pdf |chapter=Chapter 4 Memory Management |title=VAX Architecture Reference Manual |date=1987 |publisher=[[Digital Equipment Corporation]] |id=EY-3459E-DP |isbn=0-932376-86-X}}</ref>{{rp|page=199}} which is very small. An OS may treat multiple pages as if they were a single larger page. For example, [[Linux]] on VAX groups eight pages together. Thus, the system is viewed as having {{nowrap|4 KB}} pages. The VAX divides memory into four fixed-purpose regions, each {{nowrap|1 [[Gigabyte|GB]]}} in size. They are:<ref name="vax-ref-manual" />{{rp|pages=200-201}}
;P0 space: Used for general-purpose per-process memory such as heaps.
;P1 space: (Or control space) which is also per-process and is typically used for supervisor, executive, [[kernel (operating system)|kernel]], user [[Stack (abstract data type)|stacks]] and other per-process control structures managed by the operating system.
;S0 space: (Or system space) which is global to all processes and stores operating system code and data, whether paged or not, including pagetables.
;S1 space: Which is unused and "Reserved to [[Digital Equipment Corporation|Digital]]".<ref name="vax-ref-manual" />{{rp|pages=200-201}}

Page tables are big linear arrays.<ref name="vax-ref-manual" />{{rp|pages=209-215}} Normally, this would be very wasteful when addresses are used at both ends of the possible range, but the page tables for P0 and P1 space are stored in the paged S0 space.<ref name="vax-ref-manual" />{{rp|pages=211-212}} Thus, there is effectively a two-level [[Tree (data structure)|tree]], allowing applications to have sparse memory layout without wasting a lot of space on unused page table entries. Unlike page table entries in most MMUs, page table entries in the VAX MMU lack an [[accessed bit]].<ref name="vax-ref-manual" />{{rp|pages=203-205}} OSes which implement paging must find some way to emulate the accessed bit if they are to operate efficiently. Typically, the OS will periodically unmap pages so that page-not-present faults can be used to let the OS set an accessed bit.

=== ARM ===
[[ARM architecture]]-based application processors implement an MMU defined by ARM's virtual memory system architecture (VMSA).  The current architecture defines [[Page table entry|PTEs]] for describing {{nowrap|4 KB}} and {{nowrap|64 KB}} pages, {{nowrap|1 MB}} sections and {{nowrap|16 MB}} super-sections; legacy versions also defined a {{nowrap|1 KB}} tiny page.  ARM uses a two-level page table if using {{nowrap|4 KB}} and {{nowrap|64 KB}} pages, or just a one-level page table for {{nowrap|1 MB}} sections and {{nowrap|16 MB}} sections.

TLB updates are performed automatically by page table walking hardware.  PTEs include read/write access permission based on privilege, cacheability information, an [[NX bit]], and a non-secure bit.<ref>{{cite web|url=http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344i/DDI0344I_cortex_a8_r3p1_trm.pdf |title=Cortex-A8 Technical Reference Manual |website=Infoventer.arm.com |access-date=2017-05-03}}</ref>

=== DEC Alpha ===
[[DEC Alpha]] processors divide memory into {{nowrap|8 KB}}, {{nowrap|16 KB}}, {{nowrap|32 KB}}, or {{nowrap|64 KB}}; the page size is dependent on the processor.<ref name="alpha-axp-arch-manual-openvms">{{cite book |url=http://bitsavers.org/pdf/dec/alpha/Sites_AlphaAXPArchitectureReferenceManual_2ed_1995.pdf |title=Alpha AXP Architecture |chapter=Part II-A / OpenVMS AXP Software |year=1995 |edition=Second |id=EY-TI32E-DP |publisher=[[Digital Press]] |isbn=1-55558-145-5}}</ref>{{rp|pages=3{{hyp}}2}}<ref name="alpha-axp-arch-manual-osf1">{{cite book |url=http://bitsavers.org/pdf/dec/alpha/Sites_AlphaAXPArchitectureReferenceManual_2ed_1995.pdf |title=Alpha AXP Architecture |chapter=Part II-B / DEC OSF/1 Software |year=1995 |edition=Second |id=EY-TI32E-DP |publisher=[[Digital Press]] |isbn=1-55558-145-5}}</ref>{{rp|pages=3{{hyp}}2}} pages.  After a TLB miss, low-level [[firmware]] machine code (here called [[PALcode]]) walks a page table.

The [[OpenVMS]] AXP PALcode and [[DEC OSF/1]] PALcode walk a three-level tree-structured page table.  Addresses are broken down into an unused set of bits (containing the same value as the uppermost bit of the index into the root level of the tree), a set of bits to index the root level of the tree, a set of bits to index the middle level of the tree, a set of bits to index the leaf level of the tree, and remaining bits that pass through to the physical address without modification, indexing a byte within the page.  The sizes of the fields are dependent on the page size; all three tree index fields are the same size.<ref name="alpha-axp-arch-manual-openvms" />{{rp|pages=3{{hyp}}2-3{{hyp}}3}}<ref name="alpha-axp-arch-manual-osf1" />{{rp|pages=3{{hyp}}1-3{{hyp}}2}} The OpenVMS AXP PALcode supports full read and write permission bits for user, supervisor, executive, and kernel modes, and also supports fault on read/write/execute bits are also supported.<ref name="alpha-axp-arch-manual-openvms" />{{rp|pages=3{{hyp}}3-3{{hyp}}6}} The DEC OSF/1 PALcode supports full read and write permission bits for user and kernel modes, and also supports fault on read/write/execute bits are also supported.<ref name="alpha-axp-arch-manual-osf1" />{{rp|pages=(II-B) 3{{hyp}}3-3{{hyp}}6}}

The [[Windows NT]] AXP PALcode can either walk a single-level page table in a virtual address space or a two-level page table in physical address space.  The upper 32 bits of an address are ignored.
For a single-level page table, addresses are broken down into a set of bits to index the page table and remaining bits that pass through to the physical address without modification, indexing a byte within the page.
For a two-level page table, addresses are broken down into a set of bits to index the root level of the tree, a set of bits to index the top level of the tree, a set of bits to index the leaf level of the tree, and remaining bits that pass through to the physical address without modification, indexing a byte within the page.  The sizes of the fields are dependent on the page size.<ref name="alpha-axp-arch-manual-nt">{{cite book |url=http://bitsavers.org/pdf/dec/alpha/Sites_AlphaAXPArchitectureReferenceManual_2ed_1995.pdf |title=Alpha AXP Architecture |chapter=Part II-C / Windows NT AXP Software |year=1995 |edition=Second |id=EY-TI32E-DP |publisher=[[Digital Press]] |isbn=1-55558-145-5}}</ref>{{rp|pages=3{{hyp}}2-3{{hyp}}4}} The Windows NT AXP PALcode supports a page being accessible only from kernel mode or being accessible from user and kernel mode, and also supports a fault on write bit.<ref name="alpha-axp-arch-manual-nt" />{{rp|page=3{{hyp}}5}}

===MIPS===
{{Unreferenced section|date=June 2023}}
The [[MIPS architecture]] supports one to 64 entries in the TLB.  The number of TLB entries is configurable at CPU configuration before synthesis.  TLB entries are dual.  Each TLB entry maps a virtual page number (VPN2) to either one of two page frame numbers (PFN0 or PFN1), depending on the least significant bit of the virtual address that is not part of the page [[Mask (computing)|mask]].  This bit and the page mask bits are not stored in the VPN2.  Each TLB entry has its own page size, which can be any value from {{nowrap|1 KB}} to {{nowrap|256 MB}} in multiples of four.  Each PFN in a TLB entry has a caching attribute, a dirty and a valid status bit.  A VPN2 has a global status bit and an OS assigned ID which participates in the virtual address TLB entry match, if the global status bit is set to zero.  A PFN stores the physical address without the page mask bits.

A TLB refill exception is generated when there are no entries in the TLB that match the mapped virtual address.  A TLB invalid exception is generated when there is a match but the entry is marked invalid.  A TLB modified exception is generated when a store instruction references a mapped address and the matching entry's dirty status is not set.  If a TLB exception occurs when processing a TLB exception, a double fault TLB exception, it is dispatched to its own [[exception handler]].

MIPS32 and MIPS32r2 support 32 bits of virtual address space and up to 36 bits of physical address space.  MIPS64 supports up to 64 bits of virtual address space and up to 59 bits of physical address space.

===Sun MMU===
The original [[Sun-1]] is a [[single-board computer]] built around the [[Motorola 68000]] microprocessor and introduced in 1982. It includes the original Sun 1 memory management unit that provides address translation, memory protection, memory sharing and memory allocation for multiple processes running on the CPU.  All access of the CPU to private on-board RAM, external [[Multibus]] memory, on-board [[I/O]] and the Multibus I/O runs through the MMU, where address translation and protection are done in a uniform fashion. The MMU is implemented in hardware on the CPU board.

The MMU consists of a context register, a [[Memory segmentation|segment]] map and a page map.  Virtual addresses from the CPU are translated into intermediate addresses by the segment map, which in turn are translated into physical addresses by the page map.  The page size is {{nowrap|2 KB}} and the segment size is {{nowrap|32 KB}} which gives 16 pages per segment.  Up to 16 contexts can be mapped concurrently.  The maximum logical address space for a context is {{nowrap|1024 pages}} or {{nowrap|2 MB.}}  The maximum physical address that can be mapped simultaneously is also {{nowrap|2 MB.}}

The context register is important in a multitasking operating system because it allows the CPU to switch between processes without reloading all the translation state information.  The 4-bit context register can switch between 16 sections of the segment map under supervisor control, which allows 16 contexts to be mapped concurrently.  Each context has its own virtual address space.  Sharing of virtual address space and inter-context communications can be provided by writing the same values in to the segment or page maps of different contexts.  Additional contexts can be handled by treating the segment map as a context cache and replacing out-of-date contexts on a least-recently used basis.

The context register makes no distinction between user and supervisor states.  Interrupts and traps do not switch contexts, which requires that all valid interrupt vectors always be mapped in page 0 of context, as well as the valid supervisor stack.<ref>Sun 68000 Board User's Manual, Sun Microsystems, Inc, February 1983, Revision B</ref>

The [[Sun-2]] workstations are similar; they are built around the [[Motorola 68010]] microprocessor and have a similar memory management unit, with {{nowrap|2 KB}} pages and {{nowrap|32 KB}} segments.  The context register has a 3-bit system context used in supervisor state and a 3-bit user context used in user state.<ref>{{cite web|url=http://bitsavers.org/pdf/sun/sun2/Sun-2_Architecture_Manual_Dec83.pdf|title=Sun-2 Architecture Manual|publisher=[[Sun Microsystems]]|date=15 December 1983|pages=9–12}}</ref>

The [[Sun-3]] workstations, except for the Sun-3/80, Sun-3/460, Sun-3/470, and Sun-3/480, are built around the [[Motorola 68020]], and have a similar memory management unit.  The page size is increased to {{nowrap|8 KB}}.  (The later models are built around the [[Motorola 68030]] and use the 68030's on-chip MMU.)

The [[Sun-4]] workstations are built around various [[SPARC]] microprocessors, and have a memory management unit similar to that of the Sun-3 workstations.

=== PowerPC ===
{{Unreferenced section|date=June 2023}}
In [[PowerPC]] G1, G2, G3, and G4 pages are normally {{nowrap|4 KB.}}  After a TLB miss, the standard PowerPC MMU begins two simultaneous lookups.  One lookup attempts to match the address with one of four or eight data block address translation (DBAT) registers, or four or eight instruction block address translation registers (IBAT), as appropriate.  The BAT registers can map linear chunks of memory as large as {{nowrap|256 MB,}} and are normally used by an OS to map large portions of the address space for the OS kernel's own use.  If the BAT lookup succeeds, the other lookup is halted and ignored.

The other lookup, not directly supported by all processors in this family, is via a so-called [[inverted page table]], which acts as a hashed off-chip extension of the TLB. First, the top four bits of the address are used to select one of 16 [[memory segmentation|segment]] registers. Then 24 bits from the segment register replace those four bits, producing a 52-bit address.  The use of segment registers allows multiple processes to share the same [[hash table]].

The 52-bit address is hashed, then used as an index into the off-chip table. There, a group of eight-page table entries is scanned for one that matches. If none match due to excessive [[hash collision]]s, the processor tries again with a slightly different [[hash function]]. If this, too, fails, the CPU traps into OS (with MMU disabled) so that the problem may be resolved. The OS needs to discard an entry from the hash table to make space for a new entry.  The OS may generate the new entry from a more normal tree-like page table or from per-mapping data structures which are likely to be slower and more space-efficient.  Support for [[NX bit|no-execute]] control is in the segment registers, leading to {{nowrap|256 MB}} granularity.

A major problem with this design is poor [[cache locality]] caused by the hash function.  Tree-based designs avoid this by placing the page table entries for adjacent pages in adjacent locations.  An operating system running on the PowerPC may minimize the size of the hash table to reduce this problem.

It is also somewhat slow to remove the page table entries of a process.  The OS may avoid reusing segment values to delay facing this, or it may elect to suffer the waste of memory associated with per-process hash tables.  G1 chips do not search for page table entries, but they do generate the hash, with the expectation that an OS will search the standard hash table via software.  The OS can write to the TLB.  G2, G3, and early G4 chips use hardware to search the hash table.  The latest chips allow the OS to choose either method.  On chips that make this optional or do not support it at all, the OS may choose to use a tree-based page table exclusively.

=== x86 ===
The [[x86]] architecture has evolved over a very long time while maintaining full software compatibility, even for OS code. Thus, the MMU is extremely complex, with many different possible operating modes.

The [[8086]]/[[8088]] and [[80186]]/80188 have no memory management unit; they support segmentation, but only to support more physical memory than a 16-bit address can support, as the segment number, in a segment register, is multiplied by 16 and added to the segment offset to generate a physical address.

The [[80286]] added an MMU that supports segmentation, but not paging. When segmentation is enabled by turning on [[protected mode]], the segment number acts as an index into a table of [[segment descriptor]]s; a segment descriptor contains a base physical address, a segment length, a presence bit to indicate whether the segment is currently in memory, permission bits, and control bits, If the offset in the segment is within the bounds specified by the segment descriptor, that offset is added to the base physical address to generate a physical address.

The [[80386]], which introduced the 32-bit [[IA-32]] version of x86, and subsequent x86 CPUs, support segmentation and paging. If paging is enabled, the base address in a segment descriptor is an address in a linear paged address space divided into {{nowrap|4 KB}} pages, so when that is added to the offset in the segment, the resulting address is a linear address in that address space; in IA-32, that address is then masked to be no larger than 32 bits.  The result may be looked up via a tree-structured page table, with the bits of the address being split as follows: 10 bits for the branch of the tree, 10 bits for the leaves of the branch, and the 12 lowest bits being directly copied to the result. 

Segment registers, used in pre-80386 CPUs to extend the address space, are not used in modern OSes, with one major exception: access to [[thread (computer science)|thread]]-specific data for applications or CPU-specific data for OS kernels, which is done with explicit use of the FS and GS segment registers. All memory access involves a segment register, chosen according to the code being executed. Except when using FS or GS, the OS ensures that the offset will be zero. Some operating systems, such as [[OpenBSD]] with its [[W^X]] feature, and Linux with the [[Exec Shield]] or [[PaX]] patches, may also limit the length of the code segment, as specified by the CS register, to disallow execution of code in modifiable regions of the address space.

Minor revisions of the MMU introduced with the [[Intel P5|Pentium]] have allowed very large {{nowrap|4 MB}} pages by skipping the bottom level of the tree (this leaves 10 bits for indexing the first level of page hierarchy with the remaining 10+12 bits being directly copied to the result).  Minor revisions of the MMU introduced with the [[Pentium Pro]] introduced the [[physical address extension]] (PAE) feature, enabling 36-bit physical addresses with 2+9+9 bits for three-level page tables and 12 lowest bits being directly copied to the result.  Large pages ({{nowrap|2 MB}}) are also available by skipping the bottom level of the tree (resulting in 2+9 bits for two-level table hierarchy and the remaining 9+12 lowest bits copied directly). In addition, the [[page attribute table]] allowed specification of cacheability by looking up a few high bits in a small on-CPU table.

[[Executable-space protection|No-execute]] support was originally only provided on a per-segment basis, making it very awkward to use.
More recent x86 chips provide a per-page [[NX bit]] (no-execute bit) in the PAE mode.
The [[W^X]], [[Exec Shield]], and [[PaX]] mechanisms described above emulate per-page non-execute support on machines with x86 processors that lack the NX bit by setting the length of the code segment, with a performance loss and a reduction in the available address space.

[[File:HSA-enabled virtual memory with distinct graphics card.svg|thumb|right|upright=1.8|[[Heterogeneous System Architecture]] (HSA) creates a unified virtual address space for CPUs, GPUs and DSPs, obsoleting the mapping tricks and data copying.]]

[[x86-64]], the 64-bit version of the x86 architecture, almost entirely removes segmentation in favor of the [[flat memory model]] used by almost all operating systems for the 386 or newer processors.  In long mode, all segment offsets are ignored, except for the FS and GS segments; linear addresses are 64-bit rather than 32-bit, with the lowest 48 bits of the address being significant.  When used with {{nowrap|4 KB}} pages, the page table tree has four levels instead of three, to handle the larger linear addresses; in some newer x86-64 processors, a [[Intel 5-level paging|fifth page table level]] can be enabled, to support 57-bit linear addresses.  In all levels of the page table, the page table entry includes an NX bit.

48-bit linear addresses are divided as follows: 16 bits unused, nine bits each for four tree levels (for a total of 36 bits), and the 12 lowest bits directly copied to the result.  With {{nowrap|2 MB}} pages, there are only three levels of page table, for a total of 27 bits used in paging and 21 bits of offset.  Some newer CPUs also support a {{nowrap|1 GB}} page with two levels of paging and {{nowrap|30 bits}} of offset.<ref name=amd-volume2>{{cite web
| url = http://support.amd.com/TechDocs/24593.pdf
| title = AMD64 Architecture Programmer's Manual Volume 2: System Programming
| date = March 2017
| access-date = 2017-12-05
}}</ref> [[CPUID]] can be used to determine if {{nowrap|1 GB}} pages are supported.

In all three cases, the {{nowrap|16 highest}} bits are required to be equal to the 48th bit, or in other words, the low {{nowrap|48 bits}} are [[sign extension|sign extended]] to the higher bits. This is done to allow further expansion of the addressable range, without compromising backwards compatibility.

57-bit linear addresses are divided as follows: 7 bits unused, nine bits each for five tree levels (for a total of 45 bits), and the 12 lowest bits directly copied to the result. The low {{nowrap|57 bits}} are sign extended.