Exercises — RISC-V base ISA (RV32I - RV64I)

Both have exactly 32 GPRs named x0–x31. The number "32" in the name RV32I is the register width (XLEN = 32 bits), not the count. RV64I also has 32 registers; they are just 64 bits wide each. Answer: 32 and 32.

x0. Reads always return $0$; writes are silently discarded (thrown away). This is why nop = addi x0, x0, 0: it computes something, then dumps the result into the trash-bin register.

32 bits (4 bytes), fixed. Fixed length means the CPU always knows where the next instruction starts without decoding the current one — fetch and decode become trivial and fast. This is a core RISC design choice.

A 12-bit signed (two's-complement) number: the top bit is the sign, the other 11 bits carry magnitude.

• Most negative: $-2^{11}=-2048$.
• Most positive: $2^{11}-1=2047$. $\text{range}=[-2048,2047]$ See figure below for how the number line wraps.

Top bit is $1$ → negative. In two's complement, all-ones = $-1$. Sign-extended to XLEN bits it is still $-1$ (0xFFFF...FF). So addi x5, x6, -1 computes $x5=x6-1$. Value added: $-1$.

The stored bits represent a signed offset in units of 2 bytes. So the effective offset is (12-bit signed value) × 2: $\text{offset}\in [-2^{12},2^{12}-2]=[-4096,+4094]\text{bytes, step }2.$ Roughly $\pm 4$ KiB. Why is bit 0 free? In base RV32I every instruction is 4-byte aligned, so a branch target's low two bits are always $0$ — the encoding could even have dropped two bits. RISC-V drops only bit 0 (not bit 1) on purpose: if the optional C (compressed) extension is present, instructions may sit on any 2-byte boundary, so bit 1 can legitimately be $1$. Dropping just the always-zero bit 0 doubles the reach while staying compatible with compressed code.

I-type layout: [31:20]=imm | [19:15]=rs1 | [14:12]=funct3 | [11:7]=rd | [6:0]=opcode.

• imm = -1 → 12 bits 1111 1111 1111.
• rs1 = 6 → 00110.
• funct3 = 000.
• rd = 5 → 00101.
• opcode = 0010011.

Concatenate:

111111111111 00110 000 00101 0010011

Group into 32 bits and read as hex:

1111 1111 1111 0011 0000 0010 1001 0011
 F    F    F    3    0    2    9    3

Machine code: 0xFFF30293.

Because the register selector fields rs1, rs2, rd are pinned to fixed bit positions across all formats. Compare S-type above with I-type ([31:20]=imm | [19:15]=rs1 | [14:12]=funct3 | [11:7]=rd): in both, rs1 sits at [19:15] and funct3 at [14:12]. A store has no rd, so those [11:7] bits (where rd would be) are recycled to hold the low 5 bits of the immediate, and the rest of the immediate goes up in [31:25]. The decoder can start reading register file entries the instant it sees the fixed rs1/rs2 bits — before the scattered immediate is understood. A small MUX re-assembles imm[11:5] : imm[4:0] into the full 12-bit value. The cost (a bit of wiring) buys parallel decode + register read, a speed win that matters for Pipelining.

0xEEF in binary is 1110 1110 1111 — 12 bits, top bit = 1 → negative. As a signed 12-bit number: $0\text{xEEF}=3823$ unsigned, but $3823-4096=-273$. Sign-extended to 32 bits: 0xFFFFFEEF. So a naive addi x10, x0, 0xEEF gives $x10=-273=$ 0xFFFFFEEF, not 0x00000EEF. The real li pseudo-instruction (see Assembler & Pseudo-instructions) detects this and emits a lui+addi pair to produce the clean positive value.

Split 0xDEADBEEF into upper 20 bits and lower 12 bits:

• Lower 12 bits = 0xEEF = 1110 1110 1111, bit 11 set → signed value $-273$.
• Upper 20 bits would naively be 0xDEADB, so lui x10, 0xDEADB gives 0xDEADB000.

Because the lower add is negative ($-273$), it will subtract, landing below our target. To compensate, round the upper part up by 1: 0xDEADB → 0xDEADC.

lui   x10, 0xDEADC     # x10 = 0xDEADC000
addi  x10, x10, -273   # + (-273)

Check the arithmetic in clean hex (no messy decimals needed):

• Note $-273=-0\text{x}111$, and 0xEEF = 0x1000 - 0x111.
• lui gives 0xDEADC000.
• Adding $-0\text{x}111$: 0xDEADC000 - 0x111 = 0xDEADBEEF.

Landing exactly on 0xDEADBEEF. ✓ (The +1 to the upper field is precisely what cancels the "borrow" caused by the negative low add.)

loop:
  addi x1, x1, -1     # counter--
  # ... loop body ...
  bne  x1, x0, loop   # if x1 != 0, branch back

Why compare with x0? RV32I has no compare-to-zero opcode — but it doesn't need one, because x0 is the constant zero. bne x1, x0, loop = "branch if x1 ≠ 0". The branch offset is negative (target is behind us), sign-extended, in 2-byte steps. With x1 = 5, let's trace: after 1st addi, x1=4, body runs (run #1), branch taken; ... after 5th addi, x1=0, body runs (run #5), branch not taken. Body executes 5 times. ✓

addw does the addition only on the low 32 bits, wrapping (modular) at 32 bits, then sign-extends the 32-bit result to 64 bits.

• Low 32 bits of x7 = 0x80000000.
• $0\text{x}80000000+0\text{x}80000000=0\text{x}1\_0000\_0000$; keep low 32 → 0x00000000.
• Sign-extend 0x00000000 (top bit 0) → 0x0000_0000_0000_0000. Answer: 0x0000000000000000 (i.e. 0). The overflow bit above 32 is simply dropped — exactly C's int wraparound behavior.

• Low 32 bits = 0x40000000.
• $0\text{x}40000000+0\text{x}40000000=0\text{x}80000000$ (fits in 32 bits, no overflow past bit 31).
• The 32-bit result 0x80000000 has bit 31 = 1 → sign-extend fills the upper 32 bits with 1s. Answer: 0xFFFFFFFF80000000. This is the subtle case: no 32-bit overflow, but the sign bit flips, so the 64-bit view becomes negative.

Where the implicit bit-0 comes from (same story as L2.3): instruction targets are at least 2-byte aligned (4-byte aligned in pure RV32I, 2-byte if the compressed C extension is present), so the least-significant bit of the target offset is always $0$. Rather than waste a stored bit on a guaranteed zero, J-type encodes the offset in units of 2 bytes — the hardware appends the implicit $0$ when it reconstructs the address. So the 20 stored bits cover a signed offset that you must multiply by 2 to read in bytes: $\text{range}=[-2^{20},2^{20}-2]\text{bytes}=[-1048576,1048574]\approx \pm 1\text{MiB}.$ The student forgot the implicit-bit doubling. True reach: ±1 MiB, not ±512 KiB.

beq = branch if equal. x0 == x0 is always true ($0=0$), so this branch is unconditionally taken, every time. It is effectively an unconditional relative jump (within branch range). This is how assemblers can synthesize a short j/b (branch always) from base instructions using the zero register — see Addressing Modes for PC-relative targets.

Register count in RV64I? ::: 32 (same as RV32I; only width changes). Signed range of a 12-bit immediate? ::: $[-2048,2047]$. Byte reach of a B-type branch? ::: $\pm 4$ KiB, in 2-byte steps. Machine code of addi x5, x6, -1? ::: 0xFFF30293. Result of addw when the 32-bit sum's bit 31 is set? ::: sign-extended → upper 32 bits all 1s.