Assembler (MIPS)

Assembler (MIPS) is the assembly language for the MIPS instruction set architecture — the RISC design that came out of John L. Hennessy’s research group at Stanford in the early 1980s and went on to power SGI workstations, DECstations, the Nintendo 64, and both of Sony’s first two PlayStation consoles. MIPS assembly is unusually regular: fixed 32-bit instructions, three encoding formats, a pure load/store memory model, and thirty-two general-purpose registers with no special cases beyond a hardwired zero. That regularity is the reason MIPS became the canonical teaching architecture for computer organization courses, and why so many programmers who have never shipped a line of MIPS code can still read it. Commercial development of the architecture has since wound down — MIPS the company pivoted to RISC-V in 2021 — but MIPS assembly remains alive in embedded firmware, in emulation and reverse-engineering work, and in classrooms worldwide.

History & Origins

The Stanford MIPS Project (1981-1984)

In 1981, John L. Hennessy and a group of graduate students at Stanford University began the MIPS project. The name was a backronym for Microprocessor without Interlocked Pipeline Stages, and it described the project’s most aggressive idea. Contemporary processors used hardware interlocks to stall the pipeline when one instruction depended on a result that was not yet available. The Stanford team proposed removing that hardware entirely and making the compiler responsible for scheduling instructions so that hazards never occurred — inserting no-ops or reordering independent work to fill the gaps.

This was part of a broader movement. The IBM 801 project under John Cocke and the Berkeley RISC project under David Patterson were pursuing the same core insight from different angles: that a small set of simple, uniform, single-cycle instructions, executed fast, could beat a rich set of complex instructions executed slowly. Where Berkeley RISC emphasized register windows, Stanford MIPS emphasized compiler-driven pipeline scheduling and an instruction encoding simple enough to decode almost for free.

By 1984 Hennessy was convinced the design had commercial potential. He and several colleagues left Stanford to found MIPS Computer Systems.

Commercialization (1985-1992)

The company’s first product, the R2000, was announced in 1985 and reached the market in 1986. It implemented the MIPS I ISA and was among the first commercial RISC microprocessors to ship. The design shipped as a chipset: the R2000 CPU paired with an R2010 floating-point coprocessor. Notably, the commercial architecture did not go as far as the research prototype — it kept some hardware interlocks, particularly for multiply and divide, because pure software interlocking proved impractical to maintain across implementations.

The R3000, introduced in 1988, was the breakout part. It appeared in SGI’s IRIS workstations and in DEC’s DECstation line, and it made MIPS a credible Unix workstation architecture. In 1991 the R4000 introduced MIPS III, extending the architecture to 64 bits — one of the earliest 64-bit microprocessor architectures, arriving well before 64-bit x86.

Despite strong technology, MIPS Computer Systems struggled financially as a systems vendor. In 1992, Silicon Graphics — already its largest customer — acquired the company in an all-stock transaction reportedly valued in the hundreds of millions of dollars.

Licensing, Consoles, and Decline (1992-2021)

Under SGI, MIPS found an enormous second market: embedded systems and game consoles. Sony’s original PlayStation (1994) used an R3000A-class CPU. The Nintendo 64 (1996) used the NEC VR4300, a MIPS III part. Networking vendors adopted MIPS cores widely for routers and set-top boxes.

In 1998, SGI — by then planning a move to Intel’s Itanium for its own systems — spun the chip division out as an independent IP licensing company, MIPS Technologies. In 1999 the company reorganized the ISA into MIPS32 and MIPS64, replacing the linear MIPS I through MIPS V progression with two clean base architectures plus optional extensions.

The final two decades were turbulent. Imagination Technologies acquired MIPS Technologies in 2013. In 2018 it was sold on to Wave Computing, which announced the MIPS Open initiative — a royalty-free release of the ISA. The first MIPS Open materials appeared in March 2019, and the initiative was shut down before the year was out. Wave filed for Chapter 11, emerged in March 2021 renamed MIPS, and announced that its future cores would be based on RISC-V — retiring the MIPS architecture in favor of an open ISA from the same RISC lineage.

Design Philosophy

MIPS assembly is the product of a small number of principles applied without exception:

Load/store architecture: Arithmetic and logical instructions operate only on registers. The only instructions that touch memory are loads and stores. There is no “add the contents of this memory location to a register” instruction, and no addressing mode more complex than base register plus 16-bit signed offset.

Fixed-width, three-format encoding: Every instruction is exactly 32 bits and word-aligned, and every instruction fits one of three formats (R, I, or J). Instruction decode is nearly trivial, which is precisely what makes a short, fast pipeline possible.

Expose the pipeline: Classic MIPS does not hide its implementation. The branch delay slot — the instruction immediately after a branch always executes, taken or not — is the pipeline’s fetch behavior made visible in the ISA. Early MIPS also had a load delay slot, where the result of a load was not available to the very next instruction. This is the “without interlocked pipeline stages” idea surviving into the shipping architecture.

Let the compiler do the work: Complexity that would cost transistors is pushed into the assembler and compiler. The assembler even synthesizes convenience instructions that do not exist in hardware.

Regularity over cleverness: There is one zero register, one link register convention, one calling convention. Whether this makes MIPS elegant or merely plain is a matter of taste, but it is what makes MIPS teachable.

Key Features

Register File

MIPS has 32 general-purpose registers, referred to either by number ($0-$31) or by their software convention names. The names are convention established by the ABI, not hardware — with the sole exception of $zero, which is genuinely hardwired to 0, and $ra, which the jal instruction writes by definition.

There is no architectural condition-code register. Comparisons write a 0 or 1 into a general-purpose register (slt, sltu), or are folded directly into the branch (beq, bne). Multiply and divide results land in the special HI and LO registers, read out with mfhi and mflo.

Three Instruction Formats

Every classic MIPS instruction is one of these:

R-type:  | opcode 6 | rs 5 | rt 5 | rd 5 | shamt 5 | funct 6 |   add, sub, and, slt, jr
I-type:  | opcode 6 | rs 5 | rt 5 |    immediate 16          |   addi, lw, sw, beq, lui
J-type:  | opcode 6 |          target 26                     |   j, jal

This is the part of MIPS that shows up on every computer architecture exam, and the reason: you can decode a MIPS instruction by hand in under a minute.

The Branch Delay Slot

In classic MIPS, the instruction after a branch or jump executes regardless of whether the branch is taken:

1
2
3
4

        beq     $t0, $t1, equal   # branch if $t0 == $t1
        addu    $t2, $t2, $t3     # DELAY SLOT: always executes
equal:
        ...

Compilers and hand-coders try to fill the slot with useful work; when nothing fits, a nop goes in. GNU as defaults to .set reorder, in which the assembler rearranges instructions and inserts nops for you. Writing .set noreorder turns that off and hands you the raw pipeline — which is what you want when the exact instruction sequence matters, and what you must remember when reading disassembly.

MIPS Release 6 removed branch delay slots, along with several legacy instructions. This makes R6 code deliberately incompatible with earlier MIPS, and is a good illustration of how a feature that made sense for a 1985 five-stage pipeline stopped making sense for a modern deeply-pipelined, out-of-order implementation.

Pseudo-Instructions

MIPS assemblers synthesize instructions that hardware does not implement, expanding them into real instructions — often using $at as scratch:

This is the compiler-does-the-work philosophy applied to the assembler itself: the programmer gets a comfortable notation, and the hardware stays small.

Hello World (SPIM / MARS)

The simulators used in teaching provide a syscall interface with service numbers in $v0. This is the version most people write first:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

        .data
msg:    .asciiz "Hello, World!\n"

        .text
        .globl main
main:
        li      $v0, 4          # service 4 = print_string
        la      $a0, msg        # address of the string
        syscall

        li      $v0, 10         # service 10 = exit
        syscall

Hello World (Linux, o32 ABI)

On Linux/MIPS with the o32 ABI, the syscall numbers are offset from 4000 and arguments go in $a0-$a3:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

        .data
msg:    .asciiz "Hello, World!\n"

        .text
        .globl __start
__start:
        li      $v0, 4004       # sys_write
        li      $a0, 1          # fd = stdout
        la      $a1, msg        # buffer
        li      $a2, 14         # length
        syscall

        li      $v0, 4001       # sys_exit
        li      $a0, 0
        syscall

The gap between these two examples trips up a lot of students: the SPIM/MARS syscall interface is a teaching convenience invented by the simulators, not something a real MIPS operating system provides.

Function Calls

The MIPS calling convention is straightforward enough to write from memory. jal puts the return address in $ra; jr $ra returns.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

sum3:                           # int sum3(int a, int b, int c)
        addu    $v0, $a0, $a1
        addu    $v0, $v0, $a2
        jr      $ra
        nop                     # delay slot

caller:
        addiu   $sp, $sp, -8    # allocate frame
        sw      $ra, 4($sp)     # save return address
        li      $a0, 1
        li      $a1, 2
        jal     sum3
        li      $a2, 3          # delay slot: last arg set here
        lw      $ra, 4($sp)
        addiu   $sp, $sp, 8
        jr      $ra
        nop

Note the delay slot in caller doing real work — setting the third argument after the jal instruction textually, but before the callee actually begins. This is idiomatic hand-written MIPS, and it is also why unfamiliar readers misread MIPS disassembly.

Evolution

MIPS I through MIPS V (1985-1996)

The original progression added capability in layers:

MIPS32 and MIPS64 (1999 onward)

In 1999 MIPS Technologies restructured everything into two base architectures — MIPS32 (32-bit) and MIPS64 (64-bit, a superset) — with optional Application-Specific Extensions and modules layered on top: DSP, MT (multithreading), VZ (virtualization), MSA (SIMD), and MIPS16e/microMIPS for code compression. Releases 1 through 5 followed over the next decade and a half, each adding modules and features while preserving compatibility.

Release 6 and nanoMIPS (2014-2018)

Release 6, announced in 2014, broke that compatibility on purpose. It removed branch delay slots, dropped MIPS16e, retired rarely-used instructions, and reworked branch encodings — a cleanup aimed at making modern high-performance implementations simpler. nanoMIPS, introduced around 2018, went the other direction: a standalone variable-length encoding (16-, 32-, and 48-bit instructions) targeted at code density for deeply embedded parts.

The RISC-V Pivot (2021)

After Wave Computing’s bankruptcy and reorganization, the company — renamed MIPS — announced in 2021 that its next-generation cores would implement RISC-V. It is a genuinely unusual ending: the architecture’s steward abandoning it for an open ISA from the same RISC tradition. RISC-V’s register conventions, instruction formats, and load/store discipline are all recognizably of a piece with MIPS.

Current Relevance

MIPS is no longer an architecture anyone starts a new chip design around, but MIPS assembly still turns up in several places:

Embedded and networking firmware: Enormous numbers of MIPS-based routers, access points, set-top boxes, and industrial devices are still deployed and still maintained. OpenWrt and the Linux kernel retain MIPS support, and firmware work on these devices regularly involves reading MIPS disassembly.

Education: This is MIPS’s most durable niche. Computer Organization and Design by Patterson and Hennessy uses MIPS as its reference architecture, and simulators keep it accessible without hardware. SPIM, written by James R. Larus at the University of Wisconsin–Madison, and MARS (MIPS Assembler and Runtime Simulator), created by Ken Vollmar and Pete Sanderson at Missouri State University with an initial release in 2005, are the two standard teaching environments. QEMU also emulates MIPS systems for full-OS work.

Emulation, romhacking, and reverse engineering: The Nintendo 64 and PlayStation homebrew and decompilation communities work in MIPS constantly. Projects that decompile N64 titles back into compilable C are, at their core, exercises in reading MIPS assembly at scale.

Security research: Because so much consumer networking gear runs MIPS, embedded vulnerability research frequently means MIPS binary analysis and exploitation.

Toolchain support remains solid: GCC, Clang/LLVM, and GNU binutils all target MIPS, and cross-toolchains are packaged by most Linux distributions.

Why It Matters

MIPS matters for two reasons that have very little to do with each other.

The first is architectural. MIPS was one of the three foundational RISC efforts — alongside IBM 801 and Berkeley RISC — that proved simple instruction sets executed quickly could beat complex ones. Its influence is broadly traceable: DEC Alpha came out of the same RISC design tradition, RISC-V — developed by David Patterson’s group at Berkeley — resembles MIPS’s structure closely enough that anyone fluent in one can largely read the other on sight, and the general RISC discipline of load/store architectures with large uniform register files became the default assumption for every new ISA designed since. John Hennessy and David Patterson shared the 2017 ACM A.M. Turing Award for this body of work.

The second is pedagogical, and arguably more consequential in day-to-day terms. MIPS is the architecture on which a very large fraction of working programmers first understood what a computer actually does — what a pipeline is, why a delay slot exists, how a stack frame is built, what the compiler is really emitting. The x86 instruction set, for all its commercial dominance, is a poor first assembly language; MIPS is a superb one, because there is almost nothing in it that exists for backward-compatibility reasons rather than design reasons.

That the architecture itself has been retired does not diminish either legacy. MIPS demonstrated an idea, taught it to a generation, and was ultimately succeeded by an open architecture built on the same principles.