Editing Memory management unit (section)

==Alternatives==

===Burroughs B5000 series, B6x00/B7x00/B5900/A-series/Unisys MCP systems===

The [[Burroughs B5000]] from 1961 was the first commercial system to support [[Virtual memory#Segmented_virtual_memory|virtual memory]] (after the [[Atlas Computer (Manchester)|Atlas]]), has no need for an external MMU.<ref>{{cite journal |last1=Tanenbaum|first1=Andrew S.|last2=Herder|first2=Jorrit N. |last3=Bos|first3=Herbert |date=May 2006 |title=Can We Make Operating Systems Reliable and Secure?|url=https://www.computer.org/csdl/mags/co/2006/05/r5044-abs.html |journal=Computer|volume=39 |issue=5 |pages=44–51 |doi=10.1109/MC.2006.156 |citeseerx=10.1.1.112.3028|s2cid=99779 }}</ref> The B5000 and its successors up to current Unisys ClearPath MCP (Libra) systems provide the two functions of an MMU — virtual memory addresses and memory protection — with a different architectural approach. Rather than add virtual memory onto a processor not designed for virtual memory, it is integrated in the core design of the processor/system so there is no requirement for an external unit to add functionality of address translation or bounds checking, resulting in unprecedented memory safety and security.

First, in the mapping of virtual memory addresses, instead of needing an MMU, the machines are [[Burroughs large systems descriptors|descriptor]]-based.<ref name="MCP Descriptor">{{cite web |title=The Descriptor |url=http://www.bitsavers.org/pdf/burroughs/LargeSystems/B5000_5500_5700/5000-20002-P_The_Descriptor_-_A_Definition_of_the_B_5000_Information_Processing_System_196102.pdf |website=Bitsavers}}</ref><ref name="Unisys-descriptor">{{cite web |title=Unisys Descriptor |url=https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86000387-514/section-000023204.html |website=Unisys}}</ref> The uppermost bit of a 48-bit memory word in the Burroughs B5000 series systems indicate whether the word is an user data or a descriptor/control word; descriptors were read-only to user processes and could only be updated by the system (hardware or operating system). Memory words in the B6x00/B7x00/B5900/A-series/Unisys MCP systems have 48 data bits and 3 tag bits (and later systems to current have 4 tag bits) words whose tag is an odd number are read-only to user processes – descriptors have a tag of 5 and code words have a tag of 3.

Each allocated memory block is given a master descriptor with the properties of the block — physical address, size, and whether it is present in main memory or not, in which case on first access the block must be allocated, or if there is an address, it is an address on secondary storage and must be loaded to main memory.  All references to code and data are made using a descriptor. When a request is made to access the block for reading or writing, the hardware checks its presence via the presence bit (pbit) in the descriptor.

A pbit<ref name="pbit">{{cite web |title=Pbits |url= https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86000387-514/section-000023194.html |website=Unisys}}</ref> of 1 indicates the presence of the block.  In this case, the block can be accessed via the physical main-memory address in the descriptor.  If the pbit is zero, a pbit interrupt<ref name="Pbit-interrupt">{{cite web |title=Pbit interrupt |url=https://public.support.unisys.com/aseries/docs/ClearPath-MCP-20.0/86000387-514/section-000023193.html |website=Unisys}}</ref> is generated for the [[Burroughs MCP|MCP]] (operating system) to make the block present.  If the address field is zero, this is the first access to this block, and it is allocated (an init (initial) pbit).  If the address field is non-zero, it is a disk address of the block, which has previously been rolled out — the block is fetched from disk, the pbit is set to one and the physical memory address updated to point to the block in memory.  This makes descriptors equivalent to a page-table entry in an MMU system, but descriptors are free of a table.

System performance can be monitored through the number of pbit interrupts, which is the count of accesses to descriptors with a zero bit.  'Init' pbits indicate initial allocations or new memory blocks, but a high level of 'other' pbits indicate that the system had to load a block from virtual memory secondary storage. In normal operation this will not occur very much. If there are above average number of other pbits occurring the system might be thrashing, indicating system overload. In production systems, the machine load will be more constant and thus the system configured or tuned to avoid thrashing.

All memory allocation is therefore completely automatic (one of the features of modern systems<ref>{{cite magazine|url=http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html |title=Design Principles Behind Smalltalk |author=Daniel H. H. Ingalls |author-link=Daniel Henry Holmes Ingalls Jr. |magazine=[[Byte Magazine]] |date=August 1981 |url-status=dead |archive-url=https://web.archive.org/web/20070927190743/http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html |archive-date=2007-09-27 }} </ref>) and there is no way to allocate blocks other than this mechanism.  There are no such calls as [[malloc]] or dealloc, since memory blocks are also automatically allocated on pbit interrupt or discarded.  The scheme is also [[lazy allocation|lazy]], since a block will not be allocated until it is actually referenced.  When memory is nearly full, the MCP examines the working set, trying compaction (since the system is segmented, not paged), deallocating read-only segments (such as code-segments which can be restored from their original copy) and, as a last resort, rolling dirty (that is updated) data segments out to disk.

Another way these systems provide a function of a MMU is in protection.  Since all accesses are via the descriptor, the hardware can check that all accesses are within bounds and, in the case of a write, that the process has write permission.  The MCP system is inherently secure and thus has no need of an MMU to provide this level of memory protection.

Blocks can be shared between processes via copy descriptors in process stacks (a stack is a special system structure representing the execution state of a process).
Thus, some processes may have write permission, whereas others do not.
Code segments are read-only, thus reentrant and shared between processes.
Copy descriptors contain a 20-bit address field giving the index of the master descriptor in the master descriptor array.
This also implements a very efficient and secure Interprocess Communication (IPC) mechanism.
Blocks can easily be relocated, since only the master descriptor needs to be updated when a block's status changes.

Another aspect is performance{{snd}} do MMU-based or non-MMU-based systems provide better performance?  MCP systems may be implemented on top of standard hardware that does have an MMU (for example, a standard PC).  Even if the system implementation uses the MMU in some way, this will not be at all visible at the MCP level.