RV32I 2: Integer Ops, Compares, Shifts, and Building Constants with lui/auipc

Part 2 looked at the shape of instructions (the six formats and immediate encoding). Part 3 covers what the integer operations inside those shapes actually compute. Nearly half of the RV32I instructions belong here, and this list is exactly what the ALU (arithmetic logic unit) has to do in a core design. At the end, we walk through by hand how to build 32-bit constants and addresses with lui and auipc.

From this part on, I verify instructions by actually running them. I loaded RISC-V programs without an operating system (bare metal) onto the virt board of QEMU 11.1.3 and printed the results over UART. The machine is a Mac M1 Max, and the compiler is riscv64-elf-gcc 16.2.

1. Integer operations at a glance

Something is conspicuously missing: there is no subi, because you can just give addi a negative number. The immediate is always sign-extended as a 12-bit signed value (−2048 to 2047). So keep in mind that the immediates of andi, ori, and xori are sign-extended too. Section 4 shows where this becomes a trap.

Many commonly used operations are not instructions but pseudo-instructions. The assembler turns each into a single real instruction.

The x0=0 rule from part 2 shines here. Eight useful operations were gained without adding a single instruction to the hardware.

2. Overflow: no flags, no exceptions

x86 and ARM look at the result of an addition and set flags such as carry and overflow. RISC-V has no such flags, and it raises no exception on overflow. The result is simply truncated to 32 bits (it wraps around in two's complement).

Without flags, what does software that needs overflow detection (big-integer arithmetic, languages that check for overflow) do? The specification gives idioms that check it with a few instructions.

• Unsigned addition: add t0, t1, t2 followed by bltu t0, t1, overflow. If the result is smaller than an operand, it overflowed.
• Signed addition (general): add t0, t1, t2, slti t3, t2, 0, slt t4, t0, t1, bne t3, t4, overflow. If "is the added value negative" differs from "did the result decrease," it overflowed.

Let's apply the last idiom to 0x7fffffff + 1. t2=1 is not negative, so t3=0. The result 0x80000000 is −2,147,483,648 as a signed number, which is less than t1=2,147,483,647, so t4=1. They differ, so it is an overflow. QEMU also gave 1.

From the design side, this decision is a big simplification. With no flag register, there is no need to track hidden dependencies between instructions (a later instruction reading an earlier instruction's flags), and since integer operations never raise exceptions, the trap path can be left out of the ALU.

3. Compare: slt and sltu

slt (set less than) compares two values as signed numbers, and sltu compares them as unsigned numbers. The same bits can give opposite answers depending on how they are read.

The third row matters. sltiu is an "unsigned" compare, but its immediate, like other I formats, is sign-extended first. The immediate −1 becomes 0xffffffff and is compared as "the largest unsigned number." So sltiu rd, rs, -1 is 0 only when rs is 0xffffffff. If you build the hardware thinking "it's an unsigned instruction, so zero-extend the immediate," you get it wrong.

There are two ways to build slt in hardware: look at the sign of the subtraction result while correcting for overflow, or compare the sign bits first.

If the signs differ, the negative one is smaller, so a's sign bit is the answer. If the signs are the same, the subtraction cannot overflow, so the sign bit of the subtraction result is the answer. For sltu, do the subtraction in 33 bits and check whether a borrow occurs. Both share the adder, so there is no need for a separate comparator.

4. Shifts and logical operations

There are three shifts. sll shifts left and fills the vacated bits with 0, srl shifts right and fills with 0, and sra shifts right and fills with the sign bit.

Look at the last row. Register shifts use only the lower 5 bits of rs2 as the shift amount. 33 is 100001 in binary, so its lower 5 bits are 1. That's why 1 was shifted once, not 33 times, giving 2. In C, shifting by 32 or more is undefined behavior, but RISC-V hardware gives this well-defined answer.

srai and srli share the same opcode and funct3. A single bit, inst[30], tells them apart (the funct7 position in the part 2 figure, the same bit as for sub and sra). Immediate shifts are I format, but the shift amount uses only the 5 bits of inst[24:20], and the field above is used like funct7.

Logical operations again call for care with immediate sign extension.

As in the third row, andi rd, rs, -2048 clears only the lower 11 bits, not the lower 12. That's because the immediate 0x800 is sign-extended to 0xfffff800. Clearing the lower 12 bits would need 0xfffff000, which a 12-bit immediate cannot represent. In that case, shift out and back with srli/slli, or build the mask with lui.

5. lui and 32-bit constants

Instructions are 32 bits, so a 32-bit constant cannot fit in a single instruction. RISC-V splits the constant into its upper 20 bits and lower 12 bits and builds it with two instructions. lui rd, imm (load upper immediate) places a 20-bit immediate in the upper bits and fills the lower 12 bits with 0. Then addi adds the lower 12 bits.

The problem is that the addi immediate is signed. If you try to build 0x12345fff with lui a0, 0x12345 and addi a0, a0, 0xfff, 0xfff is read as −1 and you get 0x12344fff. So the upper 20 bits are incremented to 0x12346, and adding −1 brings it back. The general formula is:

Adding 0x800 to c means "if the lower 12 bits are 0x800 or more, carry 1 upward." Then lo always falls within −2048 to 2047. The assembler's %hi(c) and %lo(c) perform this calculation.

I applied this formula to 1 million random 32-bit constants and 7 edge cases. Recombining hi and lo always gave back the original value, and lo was always in range. Of these, 499,908 (about half) received the +1 correction. That is expected, since the top bit of the lower 12 bits is 1 half the time.

The actual assembler expanded the li (load immediate) pseudo-instruction like this.

2048 is exactly 1 past the 12-bit signed range, so it needs two instructions. Conversely, 0xfffff800 is −2048, so a single addi does it. For 0x7ffff800, lui takes 0x80000 to make 0x80000000 (a negative number), then −2048 is added. This makes direct use of 32-bit wraparound.

6. auipc: pc-relative addresses

auipc rd, imm (add upper immediate to pc) shifts a 20-bit immediate up and adds it to the address of that auipc instruction itself. It builds an address from the distance to the current location instead of from a constant.

The la sp, _stack_top in the startup code run on QEMU is a good example. The assembler expanded it into auipc sp, 0x4 and addi sp, sp, 464. The auipc at 0x80000000 adds 0x4 << 12 = 0x4000 to get 0x80004000, and then addi adds 464 (0x1d0) to give the stack top 0x800041d0. The machine code of these two instructions contains no absolute address. Even if the whole program is loaded at a different address, the same machine code finds the same relative location. This is the foundation of position-independent code (PIC).

I checked inside main as well. The pc read with auipc was 0x80000020, and the address of the global variable target obtained with la and C's &target were both 0x800001c0 (a distance of 0x1a0).

The partner of auipc depends on the situation. If you need an address, addi adds the lower 12 bits; to read the value at that address, lw; to call a distant function, jalr (call = auipc + jalr). With this combination you can reach anywhere within ±2 GiB of the pc. The lower 12 bits of the partner instruction are also sign-extended, so the +1 correction from section 5 applies here in exactly the same way (the assembler's %pcrel_hi and %pcrel_lo).

7. Hands-on: QEMU results vs. a reference model

Every number in the tables above is a value actually executed on QEMU. I put one instruction at a time into C with inline assembly and printed the result over UART.

#define R(op, a, b) ({ uint32_t r_; \
    __asm__ volatile(op " %0,%1,%2" : "=r"(r_) : "r"(a), "r"(b)); r_; })
#define I(op, a, imm) ({ uint32_t r_; \
    __asm__ volatile(op " %0,%1," #imm : "=r"(r_) : "r"(a)); r_; })

show("sltu", m1, one, R("sltu", m1, one));      /* 0xffffffff < 1 ? */
show("sll", one, s33, R("sll", one, s33));      /* shift amount 33 */
show("sltiu", 5, -1, I("sltiu", 5, -1));        /* immediate sign extension */

To keep the compiler from computing the constants ahead of time, the inputs were placed in volatile variables. The output was compared against a Python reference model (a few lines that write out the 32-bit mask and the signed interpretation directly).

On the first run, 1 of the 15 was wrong. It was my own mistake: I put 0xff as the andi immediate in the test code but wrote 0xfff in the table. Without comparing against a reference model, a wrong number would have ended up in the post.

8. Design checklist: the ALU and its surroundings

The auipc row affects datapath design. Most instructions feed rs1 into the ALU's first input, but auipc (and the jal and branch address calculations in part 4) feed in the pc. That's why even a single-cycle core gets an "ALU input A = rs1 or pc" selector.

Summary

• RV32I's integer operations are 10 register-register instructions, 9 immediate instructions, and lui/auipc. That's all. Operations like mv, not, neg, and seqz are pseudo-instructions that make use of x0.
• There are no overflow flags or exceptions. When needed, software checks with slt/bltu, and the hardware sheds flag dependencies and the trap path.
• The immediates of sltiu, andi, and others are also sign-extended, and register shifts use only the lower 5 bits. All 15 QEMU runs matched the reference model.
• 32-bit constants and addresses are built with lui/auipc (upper 20 bits) and a partner instruction (lower 12 bits), and if bit 11 of the lower 12 bits is 1, the upper part is incremented by 1. Of 1 million random constants, 499,908 received the correction.

Next post: Part 4 covers the rest of RV32I: branches, jumps, and memory access. It runs on QEMU the six branches beq through bgeu, how function calls and returns are built with jal and jalr, sign extension of byte and halfword loads, how misaligned accesses are handled, and fence, ecall, and ebreak.

References

• The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture, Version 20240411. Section 2.4, Integer Computational Instructions (including the overflow-check idioms). https://github.com/riscv/riscv-isa-manual
• RISC-V Assembly Programmer's Manual (pseudo-instructions, %hi, %lo, %pcrel_hi). https://github.com/riscv-non-isa/riscv-asm-manual
• D. Patterson, A. Waterman, The RISC-V Reader: An Open Architecture Atlas, 2017. Chapter 2, RV32I; Chapter 3, Assembly Language
• D. Harris, S. Harris, Digital Design and Computer Architecture: RISC-V Edition, 2021. Section 5.2, Arithmetic Circuits (adders, comparators, shifters)
• QEMU virt board documentation. https://www.qemu.org/docs/master/system/riscv/virt.html