Question bank — Instruction formats and encoding

False. Every instruction is the same width, but a format may leave fields unused or repurpose their bits (e.g. I-type turns rs2+funct7 into a 12-bit immediate). Fixed width ≠ fixed field usage.

False. In RISC-V the opcode lives in the lowest 7 bits (rightmost when written), and the decoder reads it there. "Fixed position" means fixed, not necessarily leftmost — see Instruction Decode Stage.

True as a lower bound: $\lceil {\log }_{2}32\rceil =5$. But real ISAs often use a wider primary opcode plus funct sub-fields so they can add operations later without redesigning the word.

False. They're needed so a single field can hold negative numbers (like addi x1, x2, -8); the top bit is the sign bit. See Two's Complement and Sign Extension.

False — it's a trade-off. Variable (x86) gives denser code and better instruction-cache hits; fixed (RISC-V, MIPS, ARM) gives fast, parallel decode. Neither dominates; see RISC vs CISC.

True. Keeping rs1 (and rs2 where present) in fixed bit positions across formats means the Registers and the Register File read ports are wired the same way; only the immediate-assembly logic changes.

Partly false. The "spare" patterns aren't waste — they're reserved room for future instructions, and 7 bits keeps $7+5+5+5+3+7=32$ tidy. Spare opcode space is a feature, not leakage.

False. U-type (lui, auipc) places its 20 bits directly into the upper part of a 32-bit value (bits 31:12); J-type (jal) reorders and scales its 20 bits into a signed jump offset. Same width, very different plumbing.

False. The B-type immediate is stored scaled, sign-extended, and its bits are reordered/scattered. The raw field must be reassembled before it becomes the real offset — see the B-type walkthrough below.

Widening rs1/rs2/rd steals bits from the same fixed word. Going from 32 to 64 registers (5→6 bits) eats 3 extra bits across three fields, shrinking the immediate or opcode room. The budget is fixed.

The split exists so rs1 and rs2 stay in their usual positions. Keeping registers fixed simplifies the read logic; the immediate takes whatever leftover holes remain. It's a deliberate hardware win, not laziness.

The decoder reads the opcode (low 7 bits) first to learn the class, then funct3/funct7 disambiguate add vs sub within that class. Opcode leads; funct refines.

That's the unsigned range. Signed two's-complement 12 bits covers $-2048$ to $+2047$ — the same 4096 patterns, but half are negative because the top bit is a sign bit.

Zero-padding would turn $-8$ into a huge positive number. Sign-extension copies the sign bit into the new high bits, preserving value: $-8$ stays $-8$. See Two's Complement and Sign Extension.

In variable-length encoding you can't locate instruction $n+1$ until you know the length of instruction $n$ — a serial dependency. That length-finding step is the bottleneck fixed-length avoids.

They're sub-selectors that expand operations within a primary opcode class, without growing the primary opcode. They let you multiply operations while spending the primary opcode budget only once.

lui places those 20 bits into bits 31:12 and zero-fills the low 12, so the value is the immediate shifted left by 12 — a large number, used to build full 32-bit constants together with a following addi.

So the decoder can always find what kind of instruction this is before it knows anything else, letting it choose how to interpret the remaining bits. Fixed opcode position = decode can start immediately and in parallel.

The ALU operates on full 32-bit values. A 12-bit field must be widened while preserving its numeric meaning, so the sign bit is replicated — otherwise negatives would silently become large positives.

The 32-bit word is a fixed budget. Every bit spent on the opcode is unavailable to the immediate/register fields, so a bigger opcode directly shrinks how large an immediate you can encode.

Common tiny operations fit in 1 byte instead of 4, so programs occupy less memory. Denser code means more instructions fit in the same cache, raising the hit rate and easing memory bandwidth.

They need different things — three registers vs. two registers plus a number vs. one register plus a big jump distance. One rigid layout would either waste bits or run short on immediate space, so multiple formats reuse the same 32 bits differently.

They exist to build big values: U-type sets the high 20 bits of a 32-bit constant/address, and J-type reaches far-away jump targets. Neither needs rs2, so those freed bits are handed to a wide immediate instead.

Because valid branch targets always land on an aligned instruction boundary, the lowest offset bit(s) are known to be 0 and needn't be stored — so the same stored bits reach farther. Caveat: in base RV32I instructions are 4-byte aligned, so the true useful step is even coarser; the "units of 2 bytes" scaling in the spec exists because the optional compressed (C) extension allows 2-byte-aligned instructions. The walkthrough below unpacks how the scattered bits reassemble.

$\lceil {\log }_{2}1\rceil =0$ bits — you need no opcode to distinguish one thing from itself. In practice you'd still reserve bits for future growth, but mathematically zero suffices.

$\lceil {\log }_{2}64\rceil =6$ bits, used with no spare patterns — every one of the $2^6=64$ codes is assigned. Adding even one more operation would force a 7th bit.

Zero in both cases — the sign bit is 0, so signed and unsigned agree at 0. The interpretations only diverge once the top bit is 1.

The immediate is split across the two leftover regions (S-type), keeping rs1/rs2 fixed. The decoder reassembles the scattered pieces into one 12-bit value before use.

No. The maximum is $+2047$ ($2^{11}-1$); $+2048$ overflows the positive end. You'd need a different sequence (e.g. lui + addi) — a real limit assemblers handle for you.

No. The most-negative 12-bit two's-complement value is $-2^{11}=-2048$; $-2049$ falls one step below it and overflows the negative end. The signed window is asymmetric: it reaches one further negative ($-2048$) than positive ($+2047$).

The 20 bits fill bits 31:12, so the register gets that field shifted left by 12: multiples of $2^{12}=4096$ from $0$ up to $4294963200$. It sets the upper part; the low 12 bits are zero until a later addi fills them.

No — it depends on the ISA. In RISC-V opcode 0000000 is unassigned, so an all-zeros word traps as illegal (a useful safety net against jumping into zeroed memory). But other ISAs deliberately define the all-zeros pattern as a NOP (do nothing). The rule is ISA-specific, not universal.