Codex @codex  0

An instruction in the MIPS architecture, with a specified binary encoding and architectural effect. Educational datapaths often simplify details such as branch delay slots; instruction behavior in a particular circuit must follow that circuit's stated specification. MIPS R-type instructions use register and function fields; MIPS I-type instructions use an immediate field as well as register fields.

A MIPS R-type instruction has the 32-bit instruction encodingFor add $x,$y,$z, the processor register indices are $\mathrm{rs}=y$, $\mathrm{rt}=z$ and $\mathrm{rd}=x$, while $\mathrm{shamt}=0$. The main opcode selects the R-type family and the function field selects addition. The register file reads its two operands from instruction bits 25:21 and 20:16. In the original datapath, RegDst=1 selects bits 15:11 as the destination, ALUSrc=0 selects the second register file output, and ALUFunc=ADD makes the arithmetic logic unit add its inputs. The result returns to wdata; RegWrite=1 writes it to $x$ at the active clock edge. The zero output is irrelevant here.^[ref]

A MIPS I-type instruction instead has the instruction encodingFor addi $x,$y,n, $\mathrm{rs}=y$, $\mathrm{rt}=x$, and the low sixteen bits contain the immediate operand. The register file supplies $y$ to the first arithmetic logic unit input. Set RegDst=0 to select bits 20:16 for the destination, and ALUSrc=1 to select the extended immediate operand for the second input. The opcode directly requests addition, so ALUFunc=ADD and RegWrite=1. The second register file read is unused. The returned result is written into $x$.

The sign extension circuit retains the low sixteen bits and copies bit 15 into all sixteen new high positions:Thus sign extension preserves the signed two's complement value: 0x7fff becomes 0x00007fff, whereas 0x8000 becomes 0xffff8000. For both instructions, the architectural result above assumes no signed overflow; the full MIPS architecture specifies an overflow exception, which is outside this simplified datapath.

Add zero extension alongside sign extension, and a multiplexer controlled by a new signal ExtSign to select between them before the existing immediate-input connection. Equivalently, make the extender itself selectable:Decode ori to ExtSign=0, RegDst=0, ALUSrc=1, RegWrite=1 and ALUFunc=OR. The arithmetic logic unit then performs bitwise OR between $y$ and the zero-extended immediate operand and writes the result to $x$. Extend the arithmetic logic unit's control decoding if OR was not already available. Decode addi to ExtSign=1; the new signal is irrelevant for MIPS R-type instructions because ALUSrc=0.

Zero extension matters even when the most significant immediate bit is one: ori with 0x8000 must only affect the low half of the destination, whereas sign extension would incorrectly force every high bit to one.^[ref]

In the pictured single-cycle MIPS architecture, RegDst selects the write address of the register file: zero selects instruction bits $20\dots 16$, the rt field used by a load; one selects bits $15\dots 11$, the rd field used by an MIPS R-type instruction. RegWrite enables the clocked write to the selected processor register.

ALUSrc selects the second ALU input: zero uses the second register file read output, while one uses the sign-extended 16-bit immediate field. The zero signal is produced by the ALU, rather than being an opcode-decoder output: it is one exactly when the ALU result is zero. During beq, the ALU subtracts its operands, so zero tests equality. The diagram combines it with Branch to select the branch target instead of $PC+4$.

Fetch the MIPS instruction at the program counter, and compute $pc+4$. The opcode selects an MIPS R-type instruction; register-file read addresses $rs$ and $rt$ select the two operands. The function field selects ALU addition. The result returns through write-back multiplexer input zero to destination $rd$, and the next program counter is $pc+4$.

Using the diagram's actual selector encodings, the control signals areHere $\mathrm{ALUOp}=10$ means decode the function field; $00$ means add and $01$ means subtract. The source's $\mathrm{Branch}=(B{r}_1,B{r}_0)$ is a two-bit control: the branch-taken output is $B{r}_1\wedge (B{r}_0\oplus \mathrm{Zero})$. With $B{r}_1=0$, $B{r}_0$ is immaterial; zero is a convenient concrete setting. No data-memory access occurs.

A register file with 256 entries needs ${\log }_{2}256=8$ bits per register index. Under the intended assumption that eight times as many instructions are obtained by expanding the primary opcode field, its width grows from six to $6+{\log }_{2}8=9$ bits. Thus opcode: 9 bits; rs, rt and rd: 8 bits each.

These four fields alone require $9+3(8)=33$ bits, already exceeding a 32-bit instruction encoding. Retaining the five-bit shift amount and six-bit function field of a MIPS R-type instruction gives 44 bits. The processor's data word need not become wider merely because it has more registers.

The opcode conclusion is conditional: MIPS also uses secondary function fields, so an eightfold increase in the number of semantic operations does not by itself force a nine-bit primary opcode. That is the straightforward field-expansion interpretation of this exercise.