## System/161 MIPS Processor

The 32-bit MIPS is the simplest "real" 32-bit processor for which development tools are readily available; furthermore, the MIPS architecture is already widely used for teaching in various contexts. This makes it a natural choice for System/161.

The specific dialect of MIPS processor found in System/161, which for a lack of a better term we'll refer to as MIPS-161, is essentially a cache-coherent r3000, or MIPS-I. It has a few features borrowed from later models, and a couple of its own.

There are two basic versions of the MIPS-161: the System/161 1.x version and the System/161 2.x version. Distinguishing these on the fly is discussed below.

### User Mode

In user mode, the MIPS-161 behaves the same as any other 32-bit MIPS. All user instructions are fully interlocked and there are no pipeline hazards. All MIPS-I instructions are supported. MIPS-II and higher instructions are not supported, except (in System/161 2.0 and up) for the `LL` and `SC` instructions used for multiprocessor synchronization, and the `SYNC` memory barrier instruction. Please consult your favorite MIPS reference for further details.

### Kernel Mode

In kernel mode, the MIPS-161 is mostly a MIPS-I, with a few differences and a few extensions. For completeness, the following sections define the complete kernel mode interface.

### Kernel Instructions

The `WAIT` instruction has been borrowed from MIPS-II. This operation puts the processor into a low-power state and suspends execution until some external event occurs, such as an interrupt. Since the exact behavior of `WAIT` is not clearly specified anywhere I could find, the MIPS-161 behavior is as follows:

- `WAIT` should be executed with interrupts disabled or masked in the processor.
- `WAIT` will complete when any of the processor interrupt pins are activated.
- The interrupt is not serviced until it is unmasked or re-enabled.

WAIT is supported in all MIPS-161 versions.

The `TLBR`, `TLBWR`, `TLBWI`, and `TLBP` instructions are described in the MMU section below. The `RFE` instruction is described in the trap handling section, also below. The `MFC0` and `MTC0` instructions for accessing supervisor mode registers are described in the next two sections.

### Coprocessor Registers

The System/161 2.x MIPS-161 implements the MIPS-32 "select" feature for coprocessor registers: each coprocessor has up to 8 banks of 32 registers each. The "select" number identifies the register bank. Most registers of most coprocessors are in select 0. The System/161 1.x processor ignores the "select" field, so all banks will appear to mirror select 0.

Coprocessor registers are accessed with the `MFC0..3` and `MTC0..3` family of instructions, to access coprocessors 0 through 3, as follows:

    	mfc0 $4, $12, 0

loads the contents of coprocessor 0 (supervisor) register 12 select 0 (STATUS) into general-purpose register 4 (a0), and

    	mtc0 $4, $12, 0

does the reverse. If the select number is 0 (the common case) it may be omitted.

### Kernel Registers

The MIPS-161 has 11 supervisor registers in coprocessor 0. These are:

- INDEX ($0)
- RANDOM ($1)
- TLBLO ($2)
- CONTEXT ($4)
- BADVADDR ($8)
- TLBHI ($10)
- STATUS ($12)
- CAUSE ($13)
- EPC ($14)
- PRID ($15)
- CFEAT ($15 select 1) (System/161 2.x only)
- IFEAT ($15 select 2) (System/161 2.x only)

with the following bit patterns:

31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Bits |
P | 0 | SLOT | 0 | INDEX
0 | SLOT | 0 | RANDOM
PPAGE | N | D | V | G | 0 | TLBLO
PTBASE | VSHIFT | 0 | CONTEXT
BADVADDR | BADVADDR
VPAGE | ASID | 0 | TLBHI
d | c | b | a | 0 | B | T | E | M | Z | S | I | H | H | H | H | H | H | F | F | 0 | KUo | IEo | KUp | IEp | KUc | IEc | STATUS
BD | 0 | CE | 0 | H | H | H | H | H | H | F | F | 0 | EXC | 0 | CAUSE
EPC | EPC
PRID | PRID
CFEAT | CFEAT
IFEAT | IFEAT

INDEX

- P -- probe failure. Set if the `TLBP` instruction fails to find a matching entry in the TLB.
- SLOT -- TLB entry index, 0-63. This field is set by the `TLBP` instruction; it is also used by the `TLBWI` instruction.

RANDOM

- SLOT -- TLB entry index, 0-63. This field is used by the `TLBWR` instruction and is incremented on every clock cycle. See below.

TLBLO

- PPAGE -- physical page number for this TLB entry.
- N -- noncached; if set, accesses via this TLB entry will be uncached.
- D -- dirty; if set, write accesses via this TLB entry will be permitted; otherwise they will trap. See below.
- V -- valid; if set, accesses via this TLB entry will be permitted; otherwise they will trap. See below.
- G -- global; if set, the ASID field will be ignored when matching this TLB entry.

CONTEXT

- PTBASE -- base address of page table. See below.
- VSHIFT -- pre-masked-and-shifted BADVADDR for indexing page table. See below.

BADVADDR

- BADVADDR -- failing virtual address on MMU exception.

TLBHI

- VPAGE -- virtual page number for this TLB entry.
- ASID -- address space ID for this TLB entry.

STATUS

- abcdTEMZSI -- cache control and other related bits. Set to 0.
- B -- boot flag. If set, exceptions go to the boot ROM instead of the kernel.
- H -- hardware interrupt enable bit, lines 0-5.
- F -- software interrupt enable bit, lines 0-1.
- KU -- 1 if user mode, 0 if kernel mode.
- IE -- 1 if interrupts enabled, 0 if disabled. See below regarding o/p/c.

CAUSE

- BD -- 1 if exception occurred in a branch delay slot.
- CE -- coprocessor number for exception, if any.
- H -- hardware interrupt state, 1=active, lines 0-5.
- F -- software interrupt state, 1=active, lines 0-1.
- EXC -- exception code.

EPC

- EPC -- saved program counter from exception.

PRID

- PRID -- processor ID code. See discussion below.

CFEAT

- CFEAT -- compatible processor feature bits. None are defined yet, so this register will read as 0. (In later versions of System/161 it may not.) Features appearing in this register are backward-compatible; system software that is not aware of them should be expected to still operate correctly. The CFEAT register is a MIPS-161 extension; it is not found in any standard or semistandard MIPS version.

IFEAT

- IFEAT -- incompatible processor feature bits. None are defined yet, so this register will read as 0. (In later versions of System/161 it may not.) Features appearing in this register are not backward-compatible. System software that is not aware of them will probably not work. The IFEAT register is a MIPS-161 extension; it is not found in any standard or semistandard MIPS version.

### Trap Handling

When an exception occurs, the following things happen:

- The PC where the exception occurred is loaded into the EPC register.
- If this was in a branch delay slot, the EPC register is set to the address of the branch (that is, 4 is subtracted) and the BD flag in the CAUSE register is set. Software need not examine the BD flag unless the exact address of the faulting instruction is wanted, e.g. for disassembly and analysis.
- The EXC field of the CAUSE register is set to reflect what happened. The exception codes are listed below.
- For coprocessor-related exceptions the CE field of the CAUSE register is set.
- For interrupts the H and F bits of the CAUSE register are set to reflect the interrupt(s) that are active.
- For MMU exceptions the BADVADDR register is loaded with the failing address. A masked and shifted form suitable for indexing a page table is placed in the VSHIFT field of the CONTEXT register.
- The bottom six bits of the STATUS register are shifted left by two. The "o" (old) bits are lost; the "p" (previous) bits become the old bits; the "c" (current) bits become the previous bits; and the current bits are set to 0. This disables interrupts and puts the processor in kernel mode.
- Execution continues from one of five hardwired addresses according to what happened and the setting of the B (boot) bit in the STATUS register.

  The exception handler addresses are:

  B | Trap | Address
  --- | --- | ---
  1 | General | 0xbfc0 0180
  1 | UTLB | 0xbfc0 0100
  1 | Reset | 0xbfc0 0000
  0 | General | 0x8000 0080
  0 | UTLB | 0x8000 0000

  A UTLB exception is a TLB miss that occurs against the user address space (0x0000 0000 - 0x7fff ffff) and occurs because no matching TLB entry was found. Other TLB exceptions go through the General vector. This allows a fast-path TLB refill handler. See below.

  To return from an exception, one executes the following sequence:

      	jr k0
      	rfe

  where the k0 register has been loaded with the desired exception return address, either the value previously retrieved from the EPC register or some other address chosen by software. The RFE instruction is not a jump; it occurs in the delay slot of a jump. It shifts the six bottom bits of the status register right by two, undoing the shift done at exception entry time. This returns the processor to whatever interrupt state and mode (user/kernel) it was in when the exception occurred.

  Because there are three pairs of state bits, the processor can take two nested exceptions without losing state, if one is careful. This is to facilitate the fast-path TLB refill handler. See below.

  The two soft interrupt lines can be activated by writing to the CAUSE register.

  The exception codes:

  - IRQ (0) -- Interrupt
  - MOD (1) -- "Modify", TLB read-only fault
  - TLBL (2) -- TLB miss on load
  - TLBS (3) -- TLB miss on store
  - ADEL (4) -- Address error on load
  - ADES (5) -- Address error on store
  - IBE (6) -- Bus error on instruction fetch
  - DBE (7) -- Bus error on data access
  - SYS (8) -- System call
  - BP (9) -- Breakpoint instruction
  - RI (10) -- Reserved (illegal) instruction
  - CPU (11) -- Coprocessor unusable
  - OVF (12) -- Integer overflow
  - 13-15 -- Reserved
  The IBE and DBE exceptions are not MMU exceptions and do not set BADVADDR.

  ### MMU

  The MMU is the MIPS-I MMU, with a 64-entry fully associative TLB where each entry maps one 4K virtual page to one 4K physical page. The paired pages setup of later MIPS processors is not present, and there is no support for superpages.

  The processor's virtual address space is divided into four segments:

  Name | Description
  --- | ---
  kseg2 | Supervisor mode only; TLB-mapped, cacheable
  kseg1 | Supervisor mode only; direct-mapped, uncached
  kseg0 | Supervisor mode only; direct-mapped, cached
  kuseg | User and supervisor mode; TLB-mapped, cacheable

  The mapped segments are mapped via a translation lookaside buffer (TLB) with software refill. The direct-mapped segments are mapped (without use of the TLB) both to the first 512 megabytes of the physical memory space. Typically the kernel lives in kseg0, hardware devices are accessed through kseg1, and user-mode programs are run in kuseg.

  There are four MMU-related instructions:

  - `TLBR` uses the SLOT field of the INDEX register to choose a TLB entry, and reads it into the TLBLO and TLBHI registers.
  - `TLBWI` uses the SLOT field of the INDEX register to choose a TLB entry, and writes the TLBLO and TLBHI registers into it.
  - `TLBWR` uses the SLOT field of the RANDOM register to choose a TLB entry, and writes the TLBLO and TLBHI registers into it.
  - `TLBP` searches the TLB for an entry matching the TLBHI register, and sets the SLOT field of the INDEX register to its number, unless no entry was found, in which case the P field of the INDEX register is set to -1. (This makes the value of the INDEX register negative, which is easily tested.)
  The INDEX field of the RANDOM register ranges from 8 to 63; it is incremented on every instruction executed, which is not very random but apparently adequate for the purpose, which is to fill the TLB rapidly and effectively. Entries 0 through 7 of the TLB are never touched by `TLBWR` and can be used for reserved or special mappings.

  The processor is built to support a fast-path TLB refill handler, which is invoked via the UTLB exception vector (see above). The idea is that the OS maintains page tables in virtual memory using the kseg2 region (see above) and loads the base address of the page table into the PTBASE field of the CONTEXT register. Each page table entry is a 4-byte quantity suitable for loading directly into the TLBLO register; 1024 of these fit on a 4K page, so each page table page maps 4MB and it takes 512 pages, or 2MB of virtual space, to map the whole 2GB user address space. (Since these are placed in virtual memory, only the page table pages that are used need be materialized.) With this setup, the UTLB exception handler can then read the CONTEXT register and use the resulting value to load directly from the page table. If this fails because that section of the page table is not materialized, a second (non-UTLB) exception occurs. Careful register usage and the three-deep nesting of the bottom part of the STATUS register allows the general-purpose exception handler to recover from this condition and proceed as desired. On success, the UTLB handler can then unconditionally write the PTE it got into the TLB. If the V (valid) bit is not set, on return from the UTLB handler another exception will occur; however, because a matching (though not valid) TLB entry exists, this will not be a UTLB exception, and the general exception handler will get control and can schedule pagein or whatever.

  There are a number of possible other ways to use the UTLB handler, of course. One simple way is to just have it jump to the general-purpose exception handler.

  As noted above, the V (valid) bit does not prevent a TLB entry from being "matching". A TLB entry is matching if both of the following are true:

  - The VPAGE of the entry matches the virtual address being translated, and
  - either the ASID of the entry matches the ASID currently loaded into the TLBHI register, or the entry has the G (global) flag set.

  One must never load the TLB in such a fashion that two (or more) entries can match the same virtual address. If this happens, the processor shuts down and is unrecoverable except by hard reset. Since there is no way to prevent entries from matching, one should clear the TLB by loading each entry with a distinct VPAGE, and use VPAGEs from the kseg0 or kseg1 regions that will never be presented to the MMU for translation. To reset the TLB at startup, since it is not cleared by processor reset, one should use a second, potentially larger, set of distinct VPAGEs and check that each is not already present before loading it.

  There is no way to tell if a TLB entry has been used, or how recently it has been used. Nor is there a direct way to tell if a TLB entry has been used for writing. The D ("dirty") bit can be used for this purpose with software support, as follows:

  - When the TLB entry is first loaded, clear the D bit. This will make the MMU treat the translation as read-only.
  - Upon a write, a MOD exception will occur. If writing through this translation is legal, set the D bit in the TLB and anywhere else in the virtual memory system data structures that might be desired. The page is now dirty, and the processor will write to it freely.
  - When the page is written back or otherwise cleaned, or on a periodic basis to measure usage over time, flush the TLB entry or reload it with the D bit clear again.

  The MMU exceptions are as follows:

  - MOD -- attempt to write through a TLB entry whose D bit is not set. Software should respond either by making the TLB entry writable or treating the condition as a failure.
  - TLBL -- TLB miss (entry not present, or entry not valid) on a data read. If the address was in kuseg and the entry was not present, the UTLB handler is invoked. Otherwise the general exception handler is invoked. The failing address is placed in BADVADDR, and as noted above in the VSHIFT field of the CONTEXT register. The VPAGE field of the TLBHI register is also loaded. Software should respond by loading a matching and valid translation, or treating the condition as a failure.
  - TLBS -- TLB miss on store. Otherwise the same as TLBL.
  - ADEL -- address error on load. An address error is either an unaligned access or an attempt to access kernel memory while in user mode. Software should respond by treating the condition as a failure.
  - ADES -- same as ADEL, but for stores.

  ### Cache Control

  The MIPS-I has a remarkably painful cache and cache control architecture. While the MIPS-161 exhibits the same cache control bits in the STATUS register, it is in fact cache-coherent and there is no need to flush, examine, or otherwise touch the cache subsystem. In fact, doing any of these things in the MIPS-I fashion will result in undefined behavior.

  Since normal MIPS processors have split instruction and data caches, and future System/161 releases may include more cache handling, it is recommended that all necessary flushes of the instruction cache be included and stubbed out.

  ### Out-of-Order Execution

  Even with cache coherence, or when using uncached memory regions, processors that support out-of-execution may require so-called memory barrier instructions to ensure that memory accesses occur on the external bus (and become visible to other processors or devices) in the same order they are issued in machine code.

  In the System/161 2.x processor, the MIPS-II `SYNC` instruction can be used to wait until all pending load and store operations are complete. This guarantees that all memory updates before the `SYNC` become visible before any memory updates after the `SYNC`. All `SYNC` instructions executed on all cores and processors within a system occur in a single well defined global order.

  ### Cores

  Each MIPS-161 processor has only one core on the die. However, as noted elsewhere System/161 supports up to 32 processors on the mainboard. There is little software-visible difference between 32 single-core processors on one mainboard and 32 cores in one processor; most of what effects exist are cache-related and not modeled by System/161 in any event.

  ### Startup

  On CPU reset execution begins from the Reset vector defined above. The processor starts out in an almost completely undefined state. The cache is in an undefined state (except on the MIPS-161 this does not matter...), the TLB is in an undefined state, and the contents of the general and kernel-mode registers are all undefined, except as follows:

  - The B (boot) flag of the STATUS register is set to 1, so exceptions will go to the boot exception vectors in kseg1 instead of the kernel exception vectors in kseg0.
  - The KUc and IEc bits of the STATUS register are set to 0, so the processor is in kernel mode and interrupts are disabled.
  The code at the Reset vector must in general sort out the processor state before it can do anything else.

  In System/161, the boot ROM takes care of these issues and loads a kernel as described in the LAMEbus documentation. However, the state guaranteed by the boot ROM is only slightly more flexible: the boot ROM guarantees that the cache is in a workable state, and it provides a stack and an argument string in the a0 register. The TLB is still in an undefined state and the contents of other general and kernel-mode registers and register fields are still undefined.

  ### Identifying the Processor

  Distinguishing the MIPS-161 from an arbitrarily chosen MIPS-I is likely to be problematic: according to the lore, the PRID register values for MIPS-I processors could not reliably be used to distinguish processor types even in real deployed hardware. The recommended method is to arrange to know that you have a MIPS-161 because you are running on System/161; then the scheme below can be used to identify which version you have. If this is not feasible, you're on your own. It might be possible to detect the MIPS-161 by enabling certain cache control bits and ascertaining that they have no effect.

  The System/161 1.x processor can be distinguished from the System/161 2.x processor by fetching the value from the PRID register. The top half of the PRID register is 0 (because the MIPS-161 is not a MIPS-32 or MIPS-64) and the bottom half gives the version:

  - 0x3ff (1023) identifies System/161 1.x
  - 0xa1 (161) identifies System/161 2.x

  The processors in pre-2.0 versions of System/161 prior to 1.99.07 also report 0x3ff in the PRID register. These nonetheless support LL/SC and the on-chip timer (not documented herein yet, alas) but do not support SYNC, coprocessor register selects, or the CFEAT/IFEAT registers. The best way to detect this case is to check the LAMEbus mainboard version; if the multiprocessor mainboard is present, the processor supports LL/SC and the on-chip timer. (If the uniprocessor mainboard is present, this support might still be present, but can only be detected by direct probing, which is not recommended.) Other than this, no guarantees are made about mainboard versions and features vs. CPU versions and features. Mainboard and CPU properties can be selected independently in `sys161.conf`.

  Some ancient prerelease versions of System/161 (0.95 and earlier) reported 0xbeef in the PRID register. These versions are now long gone and can be ignored. The documentation also for a long time described the PRID value for the System/161 1.x processor as 0xbeef; this was incorrect.

  CPU features beyond those found by default in the System/161 2.x processor should be probed by checking the CFEAT and IFEAT registers, after confirming that a System/161 2.x processor is in fact present. See the descriptions of these feature bits above. (So far, there are none.)