Machine Components

The Nachos/MIPS machine is implemented by the Machine object, an instance of which is created when Nachos first starts up. The Machine object exports a number of operations and public variables that the Nachos kernel accesses directly. In the following, we describe some of the important variables of the Machine object; describing their role helps explain what the simulated hardware does.

The Nachos Machine object provides registers, physical memory, virtual memory support as well as operations to run the machine or examine its current state. When Nachos first starts up, it creates an instance of the Machine object and makes it available through the global variable machine. The following public variables are accessible to the Nachos kernel:

registers:

An array of 40 registers, which include such special registers as a stack pointer, a double register for multiplication results, a program counter, a next program counter (for branch delays), a register target for delayed loads, a value to be loaded on a delayed load, and the bad virtual address after a translation fault. The registers are number 0-39; see the file machine.h for symbolic names for the registers having special meaning (e.g., PCReg).

Although registers can be accessed directly via machine->registers[x], the Machine object provides special ReadRegister() and WriteRegister() routines for this purpose (described in more detail below).

mainMemory:

Memory is byte-addressable and organized into 128-byte pages, the same size as disk sectors. Memory corresponding to physical address x can be accessed in Nachos at machine->mainMemory[x]. By default, the Nachos MIPS machine has 31 pages of physical memory. The actual number of pages used is controlled by the NumPhysPages variable in machine.h.

Virtual Memory

Nachos supports VM through either a single linear page table or a software-managed TLB (though not simultaneously). The choice of which is in effect is controlled by initializing the tlb or pageTable variables of the machine class. When executing instructions, the Machine object uses whichever is defined, after verifying that they are not both set simultaneously.

At this point, we know enough about the Machine object to explain how it executes arbitrary user programs. First, we load the program's instructions into the machine's physical memory (e.g, the machine->mainMemory variable). Next, we initialize the machine's page tables and registers. Finally we invoke machine->Run(), which begins the fetch-execute cycle for the machine.

The Machine object provides the following operations:

Machine(bool debug)

The Machine constructor takes a single argument debug. When debug is TRUE, the MIPS simulator executes instructions in single step mode, invoking the debugger after each instruction is executed. The debugger allows one to interactively examine machine state to verify (for instance) that registers or memory contain expected values.

By default, single-stepping is disabled. It is enabled by specifying the ``-s'' command line option when starting Nachos up.

ExceptionType Translate(int virtAddr, int* physAddr, int size, bool writing)

converts virtual address virtAddr into its corresponding physical address physAddr. Translate examines the machine's translation tables (described in detail in Section 2.4) in order to perform the translation. When successful, Translate returns the corresponding physical address in physAddr. Otherwise, it returns a code indicating the reason for the failure (e.g., page fault, protection violation, etc.) Whenever a translation fails, the MIPS simulator invokes the Nachos routine RaiseException to deal with the problem. RaiseException is responsible for handling all hardware trap conditions. When RaiseException returns, the Nachos Machine assumes that the condition has been corrected an resumes its fetch-execute cycle.

Note that from a user-level process's perspective, traps take place in the same way as if the program were executing on a bare machine; a trap handler is invoked to deal with the problem. However, from the Nachos perspective, RaiseException is called via a normal procedure call by the MIPS simulator.

OneInstruction()

does the actual work of executing an instruction. It fetches the current instruction address from the PC register, fetches it from memory, decodes it, and finally executes it. Any addresses referenced as part of the fetch/execute cycle (including the instruction address given by PCReg) are translated into physical addresses via the Translate() routine before physical memory is actually accessed.

Run()

``turns on'' the MIPS machine, initiating the fetch-execute cycle. This routine should only be called after machine registers and memory have been properly initialized. It simply enters an infinite fetch-execute loop.

The main loop in Run does three things: 1) it invokes OneInstruction to actually execute one instruction, 2) it invokes the debugger, if the user has requested single-step mode on the command line, and 3) it increments a simulated clock after each instruction. The clock, which is used to simulate interrupts, is discussed in the following section.

int ReadRegister(int num)

fetches the value stored in register num.

void WriteRegister(int num, int value)

places value into register num.

bool ReadMem(int addr, int size, int* value)

Retrieves 1, 2, or 4 bytes of memory at virtual address addr. Note that addr is the virtual address of the currently executing user-level program; ReadMem invokes Translate before it accesses physical memory.

One point that should be noted is that ReadMem fails (returning FALSE), if the address translation fails (for whatever reason). Thus, if the page is not present in physical memory, ReadMem fails. ReadMem does not distinguish temporary failures (e.g., page not in memory) from hard errors (e.g., invalid virtual address).

ReadMem is used (for instance) when dereferencing arguments to system calls.

bool WriteMem(int addr, int size, int value)

writes 1, 2, or 4 bytes of value into memory at virtual address addr. The same warnings given for ReadMem apply here as well.