Role of the Memory Management Unit

Question

I know that the first instruction stored in BIOS is "mapped" to memory address 0, and that a signal on the reset pin to the microprocessor causes this instruction to be fetched, beginning the POST and all the chain-loading involved in the boot process.

I also know that there is a Memory-Management Unit (MMU?) at the hardware level. Is it in charge of doing this redirect (away from DRAM to the BIOS firmware) so that the processor can interact with the memory of the computer in a blissfully naive way? If so, what other areas (in addition to BIOS) does the MMU map into the total address space?

I know that for modern operating systems with a GUI, the displays are "bitmapped". Does the MMU map a portion of the video RAM on the video card into the global address space as well?

What about virtual memory and paging? Does the hardware MMU have any intrinsic capabilities that facilitate the virtual memory feature provided by the OS?

I may be way off.

Answer 1

At RESET, the MMU is usually 'off', i.e. it doesn't do any translation of memory addresses. So the RESET vector is retrieved from BIOS EPROM/Flash because the BIOS memory can actually be at that physical address.

The CPU will eventually switch the MMU on, when enough of the MMU's data has been set up. For example the MMU may have tables, in memory arrays, which will convert a virtual address to a physical address.

There are several types of MMU. The simplest have a base address which is an offset into physical memory, and a limit, which is the largest address that a program can access. This type is common in 32bit MCUs.

More complex MMU's will create the illusion of virtual addressing. A programs address space appears to be contiguous for program and data, but actually isn't, and some of it may be stored on an external storage system like disk or SSD.

The MMU is 'on-chip' in modern CPU's. They were separate off-chip units for some CPU's in the 70's and part of the 80's.

AN MMU has a very 'intimate' relationship with the CPU. Every access to memory goes via the MMU. The MMU can prevent any instruction completing an access to memory. For example a load or store instruction, transferring data between the CPU and memory, might have to be prevented from completing because it is using an address which is not valid. So the MMU needs a fast, synchronised integration with the CPU.

For a CPU capable of virtual addressing, the MMU can prevent an instruction completing for a 'missing' virtual memory page by interrupting the CPU in mid-instruction. That CPU state is stored, and the process to retrieve the missing page from external storage started. Other programs may be run in the meantime. Eventually the page is loaded into memory, the page 'fixed up' in the MMU tables, so that it is valid, and then the incomplete instruction rerun to completion, possibly millions of instructions later.

There is a choice about the relationship between cache memory and the MMU. A cache might be indexed by physical memory addresses, or virtual memory addresses. If the cache is indexed by virtual addresses, lookup in cache may happen in parallel with the MMU. If the cache is indexed by physical addresses, lookup happens after the MMU has translated a virtual address to a physical address.

An MMU could not map video memory into the CPU's address space unless the video card already makes the video memory look like normal memory. The MMU doesn't perform any magic, it does address translation between the CPU and memory access. The MMU is set up for each logical (OS) process, e.g. separate application. The MMU can 'hide' parts of the address space from a process, and normally does. So the MMU could prevent a process accessing video memory if it is part of the CPU's underlying address space.

It is the MMU which allows an OS to create a virtual memory environment for processes. The OS is mostly constrained to use whatever virtual address architecture the MMU provides. The OS and MMU don't have to be exactly aligned, for example OS could use bigger pages than the MMU supports, but it would be extremely awkward for the OS to try to use smaller pages.

It is the MMU which enables the OS to provide the illusion of virtual memory. Without a suitable MMU, it would be impractical to provide virtual memory.

(Without a virtual memory capable MMU, the illusion of virtual memory, containing on process, would be managed by an interpreter like the Java Virtual Machine (JVM), or the .NET runtime. They act upon every instruction to ensure the code of the Java/C# program can't damage anther program being run in the same address space.)

Typically the CPU runs in a couple of different 'modes', and the MMU wil treat an address differently depending on the mode. The OS will run in a more privileged 'mode' than a user process.

An MMU which supports virtual addressing will intercept every user-process access to memory (for both instructions and data) and convert the virtual address to a real, physical address. This translation doesn't necessarily happen. The MMU's translation tables also carry control bits, which the MMU enforces, which allow the user process permission to read, execute, or write to the physical address.

Answer 2

The "core" of a processor is a device which generates a sequence of read and write requests on one or more system buses. In a simple processor-based system, some of the address bits and control signals from the core will be used to select what device (if any) should handle each request, and some or all of the remaining bits will be given to the selected device. Typically, when a core issues a read request, it will output an address and expect the selected device to put information on the data bus; the core will sample the content of the data bus after giving the device some time to process the request. When it issues a write request, it will output an address and drive the data bus with the information to be written; the selected device will be expected to grab the data from the data bus within a certain length of time. Although processor cores generally have a certain length of time in which they expect that read and write requests should be honored, many have some form of "wait" input which can cause them to wait longer if need be.

While "simple" systems such as described above have proven useful for many purposes, it is often helpful to provide additional logic which sits between the processor and memory or I/O devices. This logic may serve to allow the use of devices which require signal timings different from those of the main processor bus (e.g. multiplexed address lines), optimize behavior with certain address sequences (e.g. when using a multiplexed address bus, watch for consecutive requests where part of the address remains constant, and process them without reloading the constant part), implement memory caching, etc. Circuitry which performs such functions will not, in and of itself, be called an MMU, but is nonetheless worth mentioning because many MMU devices incorporate such functionality within them.

The term "MMU" usually relates to a device which allows the processor to change the behavior of memory addressing ranges and--this is key--uses some form of "supervisor mode" indicator received from the processor core to allow a known-good piece of code to switch, just before running some code that may not be good, into a "user" mode which will restrict what features will be available to the processor until it's known to be running good code again. Such a design, if implemented properly, will make it possible for a system to run potentially-untrustworthy code and reap the benefits if the code is good, but limit the damage it can do if it's bad.

Note that while a typical memory management unit will include various forms of address-mapping features, it is not the support for address mapping which makes something an MMU. What's important, rather, is that it provide a means of switching between a mode where the processor can do "anything" and one where it can't. Configurability is highly desirable in an MMU, but in some cases not essential; in some cases an "MMU" might be nothing more than a wires connecting a processor's "user/supervisor" pin to an enable signal for a chip-select decoder [in which case there would be two "configurations", controlled by the core].

Incidentally, while some processors such as the 80286 have supported a variety of user/supervisor modes in their cores, current practice is to have a core support one user mode and one supervisor mode. The core needs to support that much, since it knows when it is fetching code for interrupts (which need to run as supervisor, but will start at addresses which can be known to be safe). Finer levels of access control are often handled not by having the core support more modes, but rather by saying that supervisor-mode code is unconditionally allowed to reconfigure all address-related settings, and user-mode code is allowed to do anything which the "memory-management unit" will allow it to do.