Question bank — Instruction formats — R-type, I-type, J-type (MIPS - RISC-V)

False. For R-type instructions the opcode is 0 for all of them; the actual operation (add vs sub vs and) lives in the 6-bit funct field. Opcode picks the format; funct finishes the job.

True. Fixed width is the core RISC choice: it lets fetch be a blind PC += 4 and lets the decoder slice the same bit positions every time. See Single-Cycle Datapath.

False. In binary the order is opcode, rs, rt, rd, shamt, funct — sources first, destination third. The assembler reorders from the syntax add $rd,$rs,$rt.

False. It holds only 16 bits directly. For a full 32-bit constant you build it in two instructions (lui for the top half, then ori/addi for the bottom). See Sign Extension and Immediates.

False. It stores a signed word offset relative to PC+4. Hardware computes target = (PC+4) + (imm × 4). This is PC-relative addressing — see PC-relative vs Absolute Addressing.

False. Only 26 bits are stored; the top 4 bits are inherited from the current PC, confining j to the same 256 MB region. For anywhere, use jr with a full 32-bit register.

False. In lw $rt, off($rs) the loaded word is written into rt, so rt is the destination. In sw $rt, off($rs) the value in rt is read out, so there it's a source. Same field, opposite role.

False. Only shift instructions (sll, srl, sra) use shamt; for add, sub, and, etc. it is simply 0. The field exists for the ops that need it and is ignored otherwise.

False. It loses nothing, because instruction addresses are always multiples of 4 (word-aligned). The low two bits of any legal target are already 00, so storing word counts instead of byte counts is free reach, not lost information.

True. A branch offset can go backward (loops), so it is signed and sign-extended. The J-type field is an unsigned chunk pasted between PC's top bits and two trailing zeros — no sign involved. See Sign Extension and Immediates.

Swapped. It is opcode=0, funct=32 (0x20). Opcode 0 flags R-type; funct 32 names add. The student inverted the two fields.

Reversed. $s3 is the base address (rs); $t0 (rt) receives the loaded word. The syntax rt, offset(rs) puts the destination first, the base inside the parentheses.

Off by one instruction. The base is PC+4, not PC: target = (PC+4) + imm×4. MIPS uses the address of the following instruction as the reference point.

Wrong tail width. Only two zeros are appended (word alignment), not four: 4 + 26 + 2 = 32. Appending four zeros would give 36 bits.

Miscounted funct. funct is 6 bits, not 5: 6+5+5+5+5+6 = 32. No padding bit exists in MIPS formats.

No. Both keep opcode 0; only their funct codes differ (add=32, sub=34). Opcode stays fixed for the whole R-type family.

False premise. The destination is repurposed onto rt. addi $rt,$rs,imm writes the result into rt. Losing the rd field doesn't lose the destination — it relocates it.

To keep decoding uniform and cheap: the same bit positions feed the same hardware wires (register file ports, immediate path). Three rulebooks cover all needs while the decoder stays a small fixed circuit. See Control Unit and Decoding.

MIPS has $2^5=32$ registers, and naming one of 32 things needs ${\log }_{2}32=5$ bits — no more, no less. See MIPS Register File and Conventions.

It saves opcode space. One opcode value plus a 6-bit funct yields up to $2^6=64$ register operations without consuming 64 precious opcode slots that I- and J-type also need.

Branches target nearby code (loops, ifs), so a small signed PC-relative offset both fits in 16 bits and lets code be relocated freely. Jumps target far labels (function calls), needing the wider 26-bit absolute-ish field. See PC-relative vs Absolute Addressing.

The two low bits of any instruction address are always 00, so storing them would waste bits. Counting in words and shifting left by 2 in hardware multiplies the reach fourfold for free (±128 KB instead of ±32 KB).

j is confined to its 256 MB PC region (top 4 bits fixed). jr reads a full 32-bit register, so it can reach anywhere — essential for returning from calls and for long-distance transfers.

The 16-bit immediate consumes the bits that R-type spent on rd, shamt, and funct ($5+5+6=16$). Something had to go to make room for the constant, so I-type keeps only rs and rt.

A trick question — lw has no funct field. It is I-type, whose layout ends in a 16-bit immediate, not opcode 0 + funct. Only R-type instructions carry funct.

target = (PC+4) + 0×4 = PC+4, i.e. control simply falls through to the next instruction — a harmless no-effect branch, not an infinite loop.

Yes. The immediate is signed; a negative value means the target is behind the branch (target = PC+4 + imm×4 < PC). This is exactly how backward loops are built.

It cannot cross it. The top 4 bits are forced to match the current PC, so a j whose intended target lies in another region silently lands in the wrong place — the assembler must instead use jr (via a register holding the full address).

It is set to 0 and ignored by the ALU. The field is only meaningful for sll, srl, sra; for everything else it is inert padding-with-a-purpose.

The all-zero word 0x00000000 decodes as R-type with funct = 0, which is sll $0,$0,0 — a shift of register $0 by 0. Since $0 is hardwired to zero, this is the canonical nop (no operation).

None in the register file. sw $rt, off($rs) writes to memory; rt is a source (the data), rs is a source (the base). No register receives a result, unlike lw.