CS计算机代考程序代写 cache mips scheme computer architecture RISC-V assembler x86 arm javascript compiler deep learning prolog assembly Java flex Excel algorithm android In Praise of The RISC-V Reader

40 CHAPTER3. RISC-VASSEMBLYLANGUAGE
sp = bfff fff0hex
Stack
Dynamic data
Static data
Text
Reserved
1000 0000hex pc = 0001 0000hex
0
Figure 3.10: RV32I allocation of memory to program and data. The high addresses are the top of the figure and the low addresses are the bottom. In this RISC-V software convention, the stack pointer (sp) starts at bfff fff0hex and grows down toward the Static data. The text (program code) starts at 0001 0000hex and includes the statically-linked libraries. The Static data starts immediately above the text region; in this example, we assume that address is 1000 0000hex. Dynamic data, allocated in C by malloc(), is just above the Static data. Called the heap, it grows upward toward the stack. It includes the dynamically-linked libraries.
3.4 Linker
Rather than compile all the source code every time one file changes, the linker allows individ- ual files to be compiled and assembled separately. It “stitches” the new object code together with existing machine language modules, such as libraries. It derives its name from one of its tasks, which is to all edit the links of the jump and link instructions in the object file. In fact, linker is short for link editor, which was the historical name of this step in Figure 3.1. In Unix systems, the input to the linker are files with the .o suffix (e.g., foo.o, libc.o ), and its output is the a.out file. For MS-DOS, the inputs are files with the suffix .OBJ or .LIB and the output is a .EXE file.
Figure 3.10 shows the addresses of the regions of memory allocated for code and data in a typical RISC-V program. The linker must adjust the program and data addresses of instructions in all the object files to match addresses in this figure. It is less work for the linker if the input files are position independent code (PIC). PIC means that all the branches to instructions and references to data inside the file are correct wherever the code is placed. As mentioned in Chapter 2, the PC-relative branch of RV32I makes PIC much easier to fulfill.
In addition to the instructions, each object file contains a symbol table that includes all the labels in the program that must be given addresses as part of the linking process. This list includes labels to data as well as to code. Figure 3.6 has two data labels to be set (string1 and string2) and two code labels to be assigned in (main and printf). Since it’s hard to specify a 32-bit address within a single 32-bit instruction, the linker must adjust two instruc- tions per label in the RV32I code, as Figure 3.6 shows: lui and addi for data addresses, and

3.5. STATICVS.DYNAMICLINKING 41
auipc and jalr for code addresses. Figure 3.8 shows the final linked a.out version of the object file in Figure 3.7.
RISC-V compilers support several ABIs, depending on whether the F and D extensions are present. For RV32, the ABIs are named ilp32, ilp32f, and ilp32d. ilp32 means that the C language data types int, long, and pointer are all 32 bits; the optional suffix indicates how floating-point arguments are passed. In ilp32, floating-point arguments are passed in integer registers. In ilp32f, single-precision floating-point arguments are passed in floating-point registers. In ilp32d, double-precision floating-point arguments are also passed in floating- point registers.
Naturally, to pass a floating-point argument in a floating-point register, you need the cor- responding floating-point ISA extension F or D (see Chapter 5). So, to compile code for RV32I (GCC flag ‘-march=rv32i‘), you must use the ilp32 ABI (GCC flag ‘-mabi=ilp32‘). On the other hand, having floating-point instructions doesn’t mean the calling convention is required to use them; so, for example, RV32IFD is compatible with all three ABIs: ilp32, ilp32f, and ilp32d.
The linker checks that the program’s ABI matches all of its libraries. Although the com- piler supports many combinations of ISA extensions and ABIs, only a few sets of libraries might be installed. Hence, a common pitfall is attempting to link a program without having compatible libraries installed. The linker will not produce a helpful diagnostic message in this case; it will simply attempt to link with an incompatible library, then inform you of the incompatibility. This pitfall generally occurs only when compiling on one computer for a different computer (cross compiling).
Elaboration: Linker relaxation
The jump and link instruction has a 20-bit PC-relative address field, so a single instruction can jump far. While the compiler produces two instructions for each external function, quite often only one instruction is necessary. Since this optimization saves both time and space, linkers will make passes over the code to replace two instructions with one whenever it can. Because a pass might shrink distance between a call and the function so that it now fits in a single instruction, the linker keeps optimizing the code until there are no further changes. This process is called Linker relaxation, with the name referring to relaxation techniques for solving systems of equations. In addition to procedure calls, the RISC-V linker relaxes data addressing to use the global pointer when the datum lies within ±2 KiB of gp, removing a lui or auipc. It similarly relaxes thread-local storage addressing when the datum lies within ±2 KiB of tp.
3.5 Static vs. Dynamic Linking
The prior section describes static linking, where all potential library code is linked and then loaded together before execution. Such libraries can be relatively large, so linking a popu- lar library into multiple programs wastes memory. Moreover, the libraries are bound when linked—even when they are updated later to fix bugs—forcing the statically-linked code to use the old, buggy version.
To avoid both problems, most systems today rely on dynamic linking, where the desired external function is loaded and linked to the program only after it is first called; if it’s never called, it’s never loaded and linked. Every call after the first one uses a fast link, so the dynamic overhead is only paid once. Each time a program starts it links in the current version
Architects typically measure processor performance using benchmarks that are statically linked de- spite most real programs having dynamic links. The excuse is that users in- terested in performance should link statically, but it’s a poor justification.
It makes more sense to accelerate performance of real programs, not bench- marks.

42 REFERENCES
of the library functions it needs, which is how it can get the newest version. Furthermore, if multiple programs use the same dynamically linked library, the code in the library need appear only once in memory.
The code that the compiler generates resembles that for static linking. Instead of jumping to the real function, it jumps to a short (three-instruction) stub function. The stub function loads the address of the real function from a table in memory, then jumps to it. However, on the first call, the table lacks the address of the real function, but instead contains the address of the dynamic-linking routine. When invoked, the dynamic linker uses the symbol table to find the real function, copies it into memory, and then updates the table to point to the real function. Each subsequent call pays only the three-instruction overhead of the stub function.
3.6 Loader
A program like the one in Figure 3.8 is an executable file kept in the computer’s storage. When one is to be run, the loader’s job is to load it into memory and jump to the starting address. The “loader” today is the operating system; stated alternatively, loading a.out is one of many tasks of an operating system.
Loading is a little trickier for dynamically-linked programs. Instead of simply starting the program, the operating system starts the dynamic linker. It in turn starts the desired program, and then handles all first-time external calls, copies the functions into memory, and edits the program after each call to point it to the correct function.
3.7 Concluding Remarks
Keep it simple, stupid.
—Kelly Johnson, aeronautical engineer who coined the “KISS Principle,” 1960
The assembler enhances the simple RISC-V ISA with 60 pseudoinstructions that make RISC-Vcodeeasiertoreadandtowritewithoutincreasinghardwarecosts. Simplydedicat- ing one RISC-V register to zero enables many of these helpful operations. The Load Upper Immediate (lui) and Add Upper Immediate to PC (auipc) instructions make it easier for the compiler and linker to adjust addresses for external data and functions, and PC-relative branching makes it easier to help the linker with position-independent code. Having plenty of registers enables a calling convention that makes function call and return faster by reducing the number of register spills and restores.
RISC-V offers a tasteful collection of simple but impactful mechanisms that reduce cost, improve performance, and make it easier to program.
3.8 To Learn More
D. A. Patterson and J. L. Hennessy. Computer Organization and Design RISC-V Edition: The Hardware Software Interface. Morgan Kaufmann, 2017.
TIS Committee. Tool interface standard (TIS) executable and linking format (ELF) specifi- cation version 1.2. TIS Committee, 1995.
A.WatermanandK.Asanovic ́,editors. TheRISC-VInstructionSetManual,VolumeI: User-Level ISA, Version 2.2. May 2017. URL https://riscv.org/specifications/.

NOTES 43
Notes
1 http://parlab.eecs.berkeley.edu

4
RV32M: Multiply and Divide
William of Occam
(1287-1347) was an English theologian who promoted what is now called “Occam’s razor,” a preference for simplicity in the scientific method.
Entities should not be multiplied beyond necessity.
4.1 Introduction
—William of Occam, 1320
RV32M adds integer multiply and divide instructions to RV32I. Figure 4.1 is a graphical representation of the RV32M extension instruction set and Figure 4.2 lists their opcodes.
Divide is straightforward. Recall that
or alternatively
Quotient = (Dividend − Remainder) ÷ Divisor
Dividend = Quotient × Divisor + Remainder
Remainder = Dividend − (Quotient × Divisor)
RV32M has divide instructions for both signed and unsigned integers: divide (div) and di- vide unsigned (divu), which place the quotient into the destination register. Less frequently, programmers want the remainder instead of the quotient, so RV32M offers remainder (rem) and remainder unsigned (remu), which write the remainder instead of the quotient.
RV32M
multiply
_
srl can do unsigned division by 2i. For example, if a2 = 16 (24) thensrli t2,a1,4 produces the same value as divu t2,a1,a2.
multiply high
unsigned signed unsigned
_
unsigned
Figure 4.1: Diagram of the RV32M instructions.
divide remainder

4.1. INTRODUCTION
45
31 2524
20 19
15 14 12 11
7 6
0
0000001
rs2
rs1
000
rd
0110011
0000001
rs2
rs1
001
rd
0110011
0000001
rs2
rs1
010
rd
0110011
0000001
rs2
rs1
011
rd
0110011
0000001
rs2
rs1
100
rd
0110011
0000001
rs2
rs1
101
rd
0110011
0000001
rs2
rs1
110
rd
0110011
0000001
rs2
rs1
111
rd
0110011
R mul
R mulh R mulhsu R mulhu R div
R divu
R rem
R remu
Figure 4.2: RV32M opcode map has instruction layout, opcodes, format type, and names. (Table 19.2 of [Waterman and Asanovic ́ 2017] is the basis of this figure.)
# Compute unsigned division of a0 by 3 using multiplication.
0: aaaab2b7
4: aab28293
8: 025535b3
c: 0015d593
lui t0,0xaaaab # t0 = 0xaaaaaaab
addi t0,t0,-1365 # = ~ 2^32 / 1.5
mulhu a1,a0,t0 # a1 = ~ (a0 / 1.5)
srli a1,a1,0x1 # a1 = (a0 / 3)
Figure 4.3: RV32M code to divide by a constant by multiplying. It takes careful numerical analysis to show that this algorithm works for any dividend, and for some other divisors, the correction step is more complicated. The proof of correctness, and the algorithm for generating the reciprocals and correction steps, is in [Granlund and Montgomery 1994].
The multiply equation is simply:
P roduct = M ultiplicand × M ultiplier
It’s more complicated than divide because the size of the product is the sum of the sizes of the multiplier and the multiplicand; multiplying two 32-bit numbers yields a 64-bit product. To produce a properly signed or unsigned 64-bit product, RISC-V has four multiply instructions. To get the integer 32-bit product—the lower 32-bits of the full product—use mul. To get the upper 32 bits of the 64-bit product, use mulh if both operands are signed, mulhu if both operands are unsigned, and mulhsu is one is signed, and the other is unsigned. Since it would complicate the hardware to write the 64-bit product into two 32-bit registers in one instruction, RV32M requires two multiply instructions to produce the 64-bit product.
For many microprocessors, integer division is a relatively slow operation. As mentioned above, right shifts can replace unsigned division by powers of 2. It turns out that division by other constants can be optimized, too, by multiplying by the approximate reciprocal then applying a correction to the upper half of the product. For example, Figure 4.3 shows the code for unsigned division by 3.
What’s Different? ARM-32 long had multiply but no divide instruction. Divide didn’t become mandatory until 2005, almost 20 years after the first ARM processor. MIPS-32 uses special registers (HI and LO) as the sole destination registers for multiply and divide instructions. While this design reduced the complexity of early MIPS implementations, it takes an extra move instruction to use the result of the multiply or divide, potentially reducing performance. The HI and LO registers also increase the architectural state, making it slightly slower to switch between tasks.
sll can do signed and unsigned mul- tiplication by 2i. For example, if a2 = 16 (24) thenslli t2,a1,4 produces the same value asmul t2,a1,a2.
For almost all pro- cessors, multiplies are slower than shifts or adds and divides are much slower than multiplies.

46
NOTES
4.2
Elaboration: mulh and mulhu can check for overflow in multiplication.
There is no overflow when using mul for unsigned multiplication if the result of mulhu is zero. Similarly, there is no overflow when using mul for signed multiplication if all bits in the result of mulh match the sign bit of the result of mul, i.e., equals 0 if positive or ffff ffffhex if negative.
Elaboration: It’s also easy to check for divide by zero.
Just add a beqz test of the dividend before the divide. RV32I doesn’t trap on divide by zero because few programs want that behavior, and the ones that do can easily check for zero in software. Of course, divides by constants never need checks.
Elaboration: mulhsu is useful for multi-word signed multiplication.
mulhsu generates the upper half of the product when the multiplier is signed and the multipli- cand is unsigned. It is as a substep of multi-word signed multiplication when multiplying the most-significant word of the multiplier (which contains the sign bit) with the less-significant words of the multiplicand (which are unsigned). This instruction improves performance of multi-word multiplication by about 15%.
Concluding Remarks
The cheapest, fastest, and most reliable components are those that aren’t there.
—C. Gordon Bell, architect of prominent minicomputers
To offer the smallest RISC-V processor for embedded applications, multiply and divide are part of the first optional standard extension of RISC-V. Nevertheless, many RISC-V proces- sors will include RV32M.
4.3 To Learn More
T. Granlund and P. L. Montgomery. Division by invariant integers using multiplication. In ACM SIGPLAN Notices, volume 29, pages 61–72. ACM, 1994.
A.WatermanandK.Asanovic ́,editors. TheRISC-VInstructionSetManual,VolumeI: User-Level ISA, Version 2.2. May 2017. URL https://riscv.org/specifications/.
Notes
1 http://parlab.eecs.berkeley.edu

NOTES 47

5
RV32F and RV32D: Single- and Double-Precision Floating Point
Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.
—Antoine de Saint Exup’ery, L’Avion, 1940
5.1 Introduction
Although RV32F and RV32D are separate, optional instruction set extensions, they are often included together. Given single- and double-precision (32- and 64-bit) versions of nearly all floating-point instructions, for brevity we present them in one chapter. Figure 5.1 is a graphical representation of the RV32F and RV32D extension instruction sets. Figure 5.2 lists the opcodes of RV32F and Figure 5.3 lists the opcodes of RV32D. Like virtually all other modern ISAs, RISC-V obeys the IEEE 754-2008 floating-point standard [IEEE Standards Committee 2008].
5.2 Floating-Point Registers
RV32F and RV32D use 32 separate f registers instead of the x registers. The main reason for the two sets of registers is that processors can improve performance by doubling the register capacity and bandwidth by having two sets of registers without increasing the space for the register specifier in the cramped RISC-V instruction format. The major impact on the instruction set is to have new instructions to load and store the f registers and to transfer data between the x and f registers. Figure 5.4 lists the RV32D and RV32F registers and their names as determined by the RISC-V ABI.
If a processor has both RV32F and RV32D, the single-precision data uses only the lower 32 bits of the f registers. Unlike x0 in RV32I, register f0 is not hardwired to 0 but is an alterable register like all the other 31 f registers.
The IEEE 754-2008 standard provides several ways to round floating-point arithmetic, which are helpful to determine error bounds and in writing numerical libraries. The most accurate and most common is round to nearest even (RNE). The rounding mode is set in the floating-point control and status register fcsr. Figure 5.5 shows fcsr and lists the rounding options. It also holds the accrued exception flags that the standard requires.
What’s Different? Both ARM-32 and MIPS-32 have 32 single-precision floating-point registers but only 16 double-precision registers. They both map two single-precision registers
Antoine de Saint Exup’ery, L’Avion (1900-1944) was a French writer and aviator best known for the book The Little Prince.

5.3. FLOATING-POINTLOADS,STORES,ANDARITHMETIC
49
RV32F and RV32D
Floating-Point Computation
Load and Store
float load word
store doubleword
float
add
subtract multiply divide square root minimum maximum
.single .double
Conversion
float convert to
_
unsigned .single
.double
.single
from .word
.double _
float _ negative
multiply add .single
.double
.single .double
float convert to .word unsigned from
float convert to .single from .double
float convert to .double from .single Other instructions
_
negative exclusive or
.double
subtract float move to .single from .x register
float move to .x register from .single Comparison
float sign injection floatclassify .single
.single .double
compare float
equals
less than
less than or equals
Figure 5.1: Diagram of the RV32F and RV32D instructions.
into the left and right 32-bit halves of a double-precision register. x86-32 floating-point arithmetic didn’t have any registers, but used a stack instead. The stack entries were 80-bits wide to improve accuracy, so loads covert 32-bit or 64-bit operands to 80 bits, and vice versa for stores. A subsequent version of x86-32 added 8 traditional 64-bit floating-point registers and associated instructions. Unlike RV32FD and MIPS-32, ARM-32 and x86-32 overlooked instructions to move data directly between floating-point and integer registers. The only solution is to store a floating-point register in memory and then load it from memory to an integer register, and vice versa.
Elaboration: RV32FD allows the rounding mode to be set per instruction.
Called static rounding, it helps performance when you only need to change the rounding mode for one instruction. The default is to use the dynamic rounding mode in the fcsr. Static rounding is specified as an optional last argument, as fadd.s ft0, ft1, ft2, rtz will round towards zero, irrespective of fcsr. The caption of Figure 5.5 lists the names of the rounding modes.
5.3 Floating-Point Loads, Stores, and Arithmetic
RISC-V has two load instructions (flw, fld) and two store instructions (fsw, fsd) for RV32F and RV32D. The have the same addressing mode and instruction format as lw and sw.
Adding to the standard arithmetic operations (fadd.s, fadd.d, fsub.s, fsub.d, fmul.s, fmul.d, fdiv.s, fdiv.d),RV32FandRV32Dincludesquareroot(fsqrt.s, fsqrt.d). They also have minimum and maximum (fmin.s, fmin.d, fmax.s, fmax.d), which write the smaller or larger values from the pair of source operands without using a branch instruction.
Having only 16 double-precision registers was the most painful ISA er- ror in MIPS according to John Mashey, one of its architects.
Unlike integer arith- metic, the size of the product from a floating-point mul- tiply is the same as its operands. Also, RV32F and RF32D omit floating-point remainder instructions.

50
CHAPTER5. RV32FD:SINGLE/DOUBLEFLOATINGPOINT
31
27 26 25 24
20 19
15 14 12 11
7 6 0
imm[11:0]
rs1
010
rd
0000111
imm[11:5]
rs2
rs1
010
imm[4:0]
0100111
rs3
00
rs2
rs1
rm
rd
1000011
rs3
00
rs2
rs1
rm
rd
1000111
rs3
00
rs2
rs1
rm
rd
1001011
rs3
00
rs2
rs1
rm
rd
1001111
0000000
rs2
rs1
rm
rd
1010011
0000100
rs2
rs1
rm
rd
1010011
0001000
rs2
rs1
rm
rd
1010011
0001100
rs2
rs1
rm
rd
1010011
0101100
00000
rs1
rm
rd
1010011
0010000
rs2
rs1
000
rd
1010011
0010000
rs2
rs1
001
rd
1010011
0010000
rs2
rs1
010
rd
1010011
0010100
rs2
rs1
000
rd
1010011
0010100
rs2
rs1
001
rd
1010011
1100000
00000
rs1
rm
rd
1010011
1100000
00001
rs1
rm
rd
1010011
1110000
00000
rs1
000
rd
1010011
1010000
rs2
rs1
010
rd
1010011
1010000
rs2
rs1
001
rd
1010011
1010000
rs2
rs1
000
rd
1010011
1110000
00000
rs1
001
rd
1010011
1101000
00000
rs1
rm
rd
1010011
1101000
00001
rs1
rm
rd
1010011
1111000
00000
rs1
000
rd
1010011
I flw
S fsw
R4 fmadd.s R4 fmsub.s R4 fnmsub.s R4 fnmadd.s R fadd.s
R fsub.s
R fmul.s
R fdiv.s
R fsqrt.s
R fsgnj.s
R fsgnjn.s
R fsgnjx.s
R fmin.s
R fmax.s
R fcvt.w.s
R fcvt.wu.s R fmv.x.w R feq.s
R flt.s
R fle.s
R fclass.s
R fcvt.s.w
R fcvt.s.wu R fmv.w.x
Figure 5.2: RV32F opcode map has instruction layout, opcodes, format type, and names. The primary difference in the encodings between this and the next figure is bit 12 is a 0 for the first two instructions and bit 25 is a 0 for the rest of the instructions where both bits are 1 in RV32D. (Table 19.2 of [Waterman and Asanovic ́ 2017] is the basis of this figure.)

5.3. FLOATING-POINTLOADS,STORES,ANDARITHMETIC
51
31 27 26 25 24
20 19
15 14 12 11
7 6
0
imm[11:0]
rs1
011
rd
0000111
imm[11:5]
rs2
rs1
011
imm[4:0]
0100111
rs3
01
rs2
rs1
rm
rd
1000011
rs3
01
rs2
rs1
rm
rd
1000111
rs3
01
rs2
rs1
rm
rd
1001011
rs3
01
rs2
rs1
rm
rd
1001111
0000001
rs2
rs1
rm
rd
1010011
0000101
rs2
rs1
rm
rd
1010011
0001001
rs2
rs1
rm
rd
1010011
0001101
rs2
rs1
rm
rd
1010011
0101101
00000
rs1
rm
rd
1010011
0010001
rs2
rs1
000
rd
1010011
0010001
rs2
rs1
001
rd
1010011
0010001
rs2
rs1
010
rd
1010011
0010101
rs2
rs1
000
rd
1010011
0010101
rs2
rs1
001
rd
1010011
0100000
00001
rs1
rm
rd
1010011
0100001
00000
rs1
rm
rd
1010011
1010001
rs2
rs1
010
rd
1010011
1010001
rs2
rs1
001
rd
1010011
1010001
rs2
rs1
000
rd
1010011
1110001
00000
rs1
001
rd
1010011
1100001
00000
rs1
rm
rd
1010011
1100001
00001
rs1
rm
rd
1010011
1101001
00000
rs1
rm
rd
1010011
1101001
00001
rs1
rm
rd
1010011
I fld
S fsd
R4 fmadd.d R4 fmsub.d R4 fnmsub.d R4 fnmadd.d R fadd.d
R fsub.d
R fmul.d
R fdiv.d
R fsqrt.d
R fsgnj.d
R fsgnjn.d
R fsgnjx.d
R fmin.d
R fmax.d
R fcvt.s.d
R fcvt.d.s
R feq.d
R flt.d
R fle.d
R fclass.d
R fcvt.w.d
R fcvt.wu.d R fcvt.d.w
R fcvt.d.wu
Figure 5.3: RV32D opcode map has instruction layout, opcodes, format type, and names. There are some instructions in these two figures do not simply differ by data width. This figure uniquely has fcvt.s.d and fcvt.d.s while the other has fmv.x.w and fmv.w.x. (Table 19.2 of [Waterman and Asanovic ́ 2017] is the basis of this figure.)

52
CHAPTER5. RV32FD:SINGLE/DOUBLEFLOATINGPOINT
63
32 31
0
f0 / ft0
f1 / ft1
f2 / ft2
f3 / ft3
f4 / ft4
f5 / ft5
f6 / ft6
f7 / ft7
f8 / fs0
f9 / fs1
f10 / fa0
f11 / fa1
f12 / fa2
f13 / fa3
f14 / fa4
f15 / fa5
f16 / fa6
f17 / fa7
f18 / fs2
f19 / fs3
f20 / fs4
f21 / fs5
f22 / fs6
f23 / fs7
f24 / fs8
f25 / fs9
f26 / fs10
f27 / fs11
f28 / ft8
f29 / ft9
f30 / ft10
f31 / ft11
32
32
Figure 5.4: The floating-point registers of RV32F and RV32D. The single-precision registers occupy the rightmost half of the 32 double-precision registers. Chapter 3 explains the RISC-V calling convention for the floating-point registers, the rationale behind the FP Argument registers (fa0-fa7), FP Saved registers (fs0-fs11), and FP Temporaries (ft0-ft11). (Table 20.1 of [Waterman and Asanovic ́ 2017] is the basis of this figure.)
FP Temporary
FP Temporary
FP Temporary
FP Temporary
FP Temporary
FP Temporary
FP Temporary
FP Temporary
FP Saved register
FP Saved register
FP Function argument, return value FP Function argument, return value FP Function argument
FP Function argument FP Function argument FP Function argument FP Function argument FP Function argument FP Saved register
FP Saved register FP Saved register FP Saved register FP Saved register FP Saved register FP Saved register FP Saved register FP Saved register FP Saved register FP Temporary FP Temporary FP Temporary FP Temporary

5.4. FLOATING-POINTMOVESANDCONVERTS 53 31 87 543210
24 311111
Figure 5.5: Floating-point control and status register. It holds the rounding modes and the exception flags. The rounding modes are round to nearest, ties to even (rte, 000 in frm); round towards zero (rtz, 001); round down, towards −∞ (rdn, 010); round up, towards +∞ (rup, 011); and round to nearest, ties to max magnitude (rmm, 100). The five accrued exception flags indicate the exception conditions that have arisen on any floating-point arithmetic instruction since the field was last reset by software: NV is Invalid Operation; DZ is Divide by Zero; OF is Overflow; UF is Underflow; and NX is Inexact. (Figure 8.2 of [Waterman and Asanovic ́ 2017] is the basis of this figure.)
Many floating-point algorithms, such as matrix multiply, perform a multiply immediately followed by an addition or a subtraction. Hence, RISC-V offers instructions that multiply two operands and then either add (fmadd.s, fmadd.d) or subtract (fmsub.s, fmsub.d) a third operand to that product before writing the sum. It also has versions that negate the prod- uct before adding or subtracting the third operand: fnmadd.s, fnmadd.d, fnmsub.s, fnmsub.d. These fused multiply-add instructions are more accurate as well as faster than separate multiply and add instructions, because they round only once (after the add) rather than twice (after the multiply, then after the add). These instructions need a new instruction format to specify 4 registers, called R4. Figures 5.2 and 5.3 show the R4 format, which is a variation of the R format.
Instead of floating-point branch instructions, RV32F and RV32D supply comparison in- structions that set an integer register to 1 or 0 based on comparison of two floating-point registers: feq.s, feq.d, flt.s, flt.d, fle.s, fle.d. These instructions allow an integer branch instruction to jump based on a floating-point condition. For example, this code branches to Exit if f1 < f2: flt x5, f1, f2 # x5 = 1 if f1 < f2; otherwise x5 = 0 bne x5, x0, Exit # if x5 != 0, jump to Exit 5.4 Floating-Point Converts and Moves RV32F and RV32D have instructions that perform all combinations of useful conversions between 32-bit signed integers, 32-bit unsigned integers, 32-bit floating point, and 64-bit floating point. Figure 5.6 displays these 10 instructions by source data type and converted destination data type. RV32F also offers instructions to move data to x from f registers (fmv.x.w) and vice versa (fmv.w.x). 5.5 Miscellaneous Floating-Point Instructions RV32F and RV32D offer unusual instructions that help with math libraries as well as provide useful pseudoinstructions. (The IEEE 754 floating-point standard requires a way to copy and manipulate signs and to classify floating-point data, which inspired these instructions.) The first is the sign-injection instructions, which copy everything from the first source register but the sign bit. The value of the sign bit depends on the instruction: Reserved Rounding Mode (frm) Accrued Exceptions (fflags) NV DZ OF UF NX 54 CHAPTER5. RV32FD:SINGLE/DOUBLEFLOATINGPOINT To From 32b signed integer (w) 32b unsigned integer (wu) 32b floating point (s) 64b floating point (d) 32b signed integer (w) 32b unsigned integer (wu) 32b floating point (s) 64b floating point (d) – – fcvt.w.s fcvt.w.d – – fcvt.wu.s fcvt.wu.d fcvt.s.w fcvt.s.wu – fcvt.s.d fcvt.d.w fcvt.d.wu fcvt.d.s – Figure 5.6: RV32F and RV32D conversion instructions. The columns list the source data types and the rows show the converted destination data type. 1. Float sign inject (fsgnj.s, fsgnj.d): the result’s sign bit is rs2’s sign bit. 2. Float sign inject negative (fsgnjn.s, fsgnjn.d): the result’s sign bit is the opposite of rs2’s sign bit. 3. Float sign inject exclusive-or (fsgnjx.s, fsgnjx.d): the sign bit is the XOR of the sign bits of rs1 and rs2. As well as helping with sign manipulation in math libraries, sign-injection instructions provide three popular floating-point pseudoinstructions (see Figure 3.4 on page 37): 1. Copy floating-point register: fmv.s rd,rs is really fsgnj.s rd,rs,rs and fmv.d rd,rs is really fsgnj.d rd,rs,rs. 2. Negate: fneg.s rd,rs maps to fsgnjn.s rd,rs,rs and fneg.d rd,rs maps to fsgnjn.d rd,rs,rs. 3. Absolutevalue(since0⊕0=0and1⊕1=0): fabs.s rd,rs becomes fsgnjx.s rd,rs,rs and fabs.d rd,rs becomes fsgnjx.d rd,rs,rs. The second unusual floating-point instruction is classify (fclass.s, fclass.d). Classify instructions are also a great aid to math libraries. They test a source operand to see which of 10 floating-point properties apply (see the table below), and then write a mask into the lower 10 bits of the destination integer register with the answer. Only one of the ten bits is set to 1, with the rest set to 0s. x[rd] bit Meaning 0 1 2 3 4 5 6 7 8 9 f[rs1] is −∞. f[rs1] is a negative normal number. f[rs1] is a negative subnormal number. f[rs1] is −0. f[rs1] is +0. f[rs1] is a positive subnormal number. f[rs1] is a positive normal number. f[rs1] is +∞. f[rs1] is a signaling NaN. f[rs1] is a quiet NaN. 5.6. COMPARINGRV32FD,ARM-32,MIPS-32,ANDX86-32USINGDAXPY 55 void daxpy(size_t n, double a, const double x[], double y[]) { for (size_t i = 0; i < n; i++) { y[i] = a*x[i] + y[i]; } } Figure 5.8: Number of instructions and code size of DAXPY for four ISAs. It lists number of instructions per loop and total. Chapter 7 describes ARM Thumb-2, microMIPS, and RV32C. 5.6 Comparing RV32FD, ARM-32, MIPS-32, and x86-32 using DAXPY We’ll now do a head-to-head comparison using DAXPY as our floating-point benchmark (Figure 5.7). It calculates Y = a × X + Y in double-precision, where X and Y are vectors and a is a scalar. Figure 5.8 summarizes the number of instructions and number of bytes in DAXPY of programs for the four ISAs. Their code is in Figures 5.9 to 5.12. As was the case for Insertion Sort in Chapter 2, despite its emphasis on simplicity, the RISC-V version again has about the same or fewer instructions, and the code sizes of the architectures are quite close. In this example, the compare-and-execute branches of RISC-V save as many instructions as do the fancier address modes and the push and pop instructions of ARM-32 and x86-32. 5.7 Concluding Remarks Less is More. —Robert Browning, 1855. The Minimalist school of (building) architecture adopted this poem as an axiom in the 1980s. The IEEE 754-2008 floating-point standard [IEEE Standards Committee 2008] defines the floating-point data types, the accuracy of computation, and the required operations. Its suc- cess greatly reduces the difficulty of porting floating-point programs, and it also means that the floating-point ISAs are probably more uniform than are the equivalent in other chapters. Figure 5.7: The floating-point intensive DAXPY program in C. ISA ARM-32 ARM Thumb-2 MIPS-32 microMIPS x86-32 RV32FD RV32FD+RV32C Instructions 10 10 12 12 16 11 11 Per Loop 6 6 7 7 6 7 7 Bytes 40 28 48 32 50 44 28 The name DAXPY come from the formula itself: Double-precision A times X Plus Y. The single-precision version is called SAXPY. 56 NOTES 5.8 Elaboration: 16-bit, 128-bit, and decimal floating-point arithmetic The revised IEEE floating-point standard (IEEE 754-2008) describes several new formats beyond single- and double-precision, which they call binary32 and binary64. The least sur- prising addition is quadruple precision, named binary128. RISC-V has a tentative extension planned for it called RV32Q (see Chapter 11). The standard also provided two more sizes for binary data interchange, indicating that programmers might store these numbers in memory or storage but shouldn’t expect to be able to compute in these sizes. They are half-precision (binary16) and octuple precision (binary256). Despite the standard’s intent, GPUs do com- pute in half-precision as well as keep them in memory. The plan for RISC-V is to include half-precision in the vector instructions (RV32V in Chapter 8), with the proviso that pro- cessors supporting vector half-precision will also add half-precision scalar instructions. The surprising addition to the revised standard is decimal floating point, for which RISC-V has set aside RV32L (see Chapter 11). The three self-explanatory decimal formats are called decimal32, decimal64, and decimal128. To Learn More IEEE Standards Committee. 754-2008 IEEE standard for floating-point arithmetic. IEEE Computer Society Std, 2008. A.WatermanandK.Asanovic ́,editors. TheRISC-VInstructionSetManual,VolumeI: User-Level ISA, Version 2.2. May 2017. URL https://riscv.org/specifications/. Notes 1 http://parlab.eecs.berkeley.edu NOTES 57 # RV32FD (7 insns in loop; 11 insns/44 bytes total; 28 bytes RVC) # a0 is n, a1 is pointer to x[0], a2 is pointer to y[0], fa0 is a 0: 02050463 beqz 4: 00351513 slli 8: 00a60533 add Loop: c: 0005b787 fld a0,28 a0,a0,0x3 a0,a2,a0 #ifn==0,jumptoExit #a0=n*8 # a0 = address of x[n] (last element) #fa5=x[] #fa4=y[] # a2++ (increment pointer to y) # a1++ (increment pointer to x) fa5,0(a1) fa4,0(a2) a2,a2,8 a1,a1,8 10: 00063707 fld 14: 00860613 addi 18: 00858593 addi 1c: 72a7f7c3 fmadd.d fa5,fa5,fa0,fa4 # fa5 = a*x[i] + y[i] 20: fef63c27 fsd 24: fea614e3 bne Exit: 28: 00008067 fa5,-8(a2) # y[i] = a*x[i] + y[i] a2,a0,c # if i != n, jump to Loop ret # return Figure 5.9: RV32D code for DAXPY in Figure 5.7. The address in hexadecimal is on the left, the machine language code in hexadecimal is next, and then the assembly language instruction followed by a comment. The compare-and-branch instructions avoid the two compare instructions in the code of ARM-32 and x86-32. # ARM-32 (6 insns in loop; 10 insns/40 bytes total; 28 bytes Thumb-2) # r0 is n, d0 is a, r1 is pointer to x[0], r2 is pointer to y[0] 0: e3500000 cmp 4: 0a000006 beq 8: e0820180 add Loop: c: ecb16b02 vldmia 10: ed927b00 vldr 14: ee067b00 vmla.f64 d7, d6, d0 18: eca27b02 vstmia 1c: e1520000 cmp 20: 1afffff9 bne Exit: 24: e12fff1e bx r2!, {d7} r2, r0 c
lr
r0, #0 # compare n to 0
24 # if n == 0, jump to Exit
r0, r2, r0, lsl #3 # r0 = address of x[n] (last element)
r1!,{d6}
# d6 = x[i], increment pointer to x
# d7 = y[i]
# d7 = a*x[i] + y[i]
# y[i] = a*x[i] + y[i], incr. ptr to y
# i vs. n
# if i != n, jump to Loop
# return
d7,[r2]
Figure5.10:ARM-32codeforDAXPYinFigure5.7. TheautoincrementaddressingmodeofARM-32saves two instructions as compared to RISC-V. Unlike Insertion Sort, there is no need to push and pop registers for DAXPY in ARM-32.

58 NOTES
# MIPS-32 (7 insns in loop; 12 insns/48 bytes total; 32 bytes microMIPS)
# a0 is n, a1 is pointer to x[0], a2 is pointer to y[0], f12 is a
0: 10800009 beqz
4: 000420c0 sll
8: 00c42021 addu
a0,28
a0,a0,0x3
a0,a2,a0
#ifn==0,jumptoExit
# a0 = n*8 (filled branch delay slot) # a0 = address of x[n] (last element)
# a2++ (increment pointer to y) #f0=x[i]
# a1++ (increment pointer to x) #f2=y[i] #f0=a*x[i]+y[i] #ifi!=n,jumptoLoop
# y[i] = a*x[i] + y[i] (filled delay slot)
# return
# (unfilled branch delay slot)
Loop:
c: 24c60008 addiu a2,a2,8
10: d4a00000 ldc1 $f0,0(a1)
14: 24a50008 addiu a1,a1,8
18: d4c2fff8 ldc1
1c: 4c406021 madd.d
20: 14c4fffa bne
24: f4c0fff8 sdc1
Exit:
28: 03e00008 jr
2c: 00000000 nop
$f2,-8(a2)
$f0,$f2,$f12,$f0
a2,a0,c
$f0,-8(a2)
ra
Figure5.11:MIPS-32codeforDAXPYinFigure5.7. Twoofthethreebranchdelayslotsarefilledwith useful instructions. The ability to check for equality between two registers avoids the two compare instructions found in ARM-32 and x86-32. Unlike integer loads, floating-point loads have no delay slot.
# x86-32 (6 insns in loop; 16 insns/50 bytes total)
# eax is i, n is in memory at esp+0x8, a is in memory at esp+0xc
# pointer to x[0] is in memory at esp+0x14
# pointer to y[0] is in memory at esp+0x18
0: 53
1: 8b
5: c5
b: 8b 5c 24 14
f: 8b 54 24 18
13: 85 c9
15: 74 19
17: 31 c0
push ebx
mov ecx,[esp+0x8]
24 0c vmovsd xmm1,[esp+0xc]
mov ebx,[esp+0x14]
mov edx,[esp+0x18]
test ecx,ecx
je 30
xor eax,eax
# save ebx #ecxhascopyofn #xmm1hasacopyofa # ebx points to x[0]
# edx points to y[0] #comparento0
# if n==0, jump to Exit # i = 0 (since x^x==0)
4c 24 fb 10
08 4c
Loop:
19: c5 fb 10 04 c3 vmovsd
1e: c4 e2 f1 a9 04 c2 vfmadd213sd xmm0,xmm1,[edx+eax*8] # xmm0 = a*x[i] + y[i]
24: c5 fb 11 04 c2 vmovsd
29: 83 c0 01 add
2c: 39 c1 cmp
2e: 75 e9 jne
Exit:
30: 5b pop
31: c3 ret
eax,0x1
ecx,eax
19
ebx
# i++
#compareivsn
# if i!=n, jump to Loop
# restore ebx
# return
xmm0,[ebx+eax*8]
xmm0,xmm1,[edx+eax*8] # y[i] = a*x[i] + y[i]
Figure5.12:x86-32codeforDAXPYinFigure5.7. Thelackofx86-32registersisevidentinthisexample, with four variables allocated to memory that are in registers in the code for the other ISAs. It also demonstrates x86-32 idioms to compare a register to zero (test ecx,ecx) or to set a register to zero (xor eax,eax).
# xmm0 = x[i]

NOTES 59

6
RV32A: Atomic Instructions
Everything should be made as simple as possible, but no simpler.
—Albert Einstein, 1933
6.1 Introduction
Our assumption is that you already understand ISA support for multiprocessing, so our job is just to explain the RV32A instructions and what they do. If you don’t feel you have sufficient background or need a reminder, study “synchronization (computer science)” on Wikipedia (https://en.wikipedia.org/wiki/Synchronization_(computer_science)) or read Section 2.1 of our related RISC-V architecture book [Patterson and Hennessy 2017].
RV32A has two types of atomic operations for synchronization:
• atomic memory operations (AMO), and • load reserved / store conditional.
Figure 6.1 is a graphical representation of the RV32A extension instruction set and Figure 6.2 lists their opcodes and instruction formats.
Albert Einstein (1879- 1955) was the most famous scientist of the 20th century. He invented the theory of relativity and advocated building the atomic bomb for World War II.
RV32A
add
and or swap
atomic memory operation xor maximum
.word
load reserved store conditional
maximum unsigned minimum minimum unsigned
.word
Figure 6.1: Diagram of the RV32A instructions.

6.1. INTRODUCTION
61
31 25 24
20 19
15 14 12 11
7 6
0
00010
aq
rl
00000
rs1
010
rd
0101111
00011
aq
rl
rs2
rs1
010
rd
0101111
00001
aq
rl
rs2
rs1
010
rd
0101111
00000
aq
rl
rs2
rs1
010
rd
0101111
00100
aq
rl
rs2
rs1
010
rd
0101111
01100
aq
rl
rs2
rs1
010
rd
0101111
01000
aq
rl
rs2
rs1
010
rd
0101111
10000
aq
rl
rs2
rs1
010
rd
0101111
10100
aq
rl
rs2
rs1
010
rd
0101111
11000
aq
rl
rs2
rs1
010
rd
0101111
11100
aq
rl
rs2
rs1
010
rd
0101111
R lr.w
R sc.w
R amoswap.w R amoadd.w R amoxor.w R amoand.w R amoor.w
R amomin.w R amomax.w R amominu.w R amomaxu.w
Figure 6.2: RV32A opcode map has instruction layout, opcodes, format type, and names. (Table 19.2 of [Waterman and Asanovic ́ 2017] is the basis of this figure.
The AMO instructions atomically perform an operation on an operand in memory and set the destination register to the original memory value. Atomic means there can be no interrupt between the read and the write of memory, nor could other processors modify the memory value between the memory read and write of the AMO instruction.
Load reserved and store conditional provide an atomic operation across two instructions. Load reserved reads a word from memory, writes it to the destination register, and records a reservation on that word in memory. Store conditional stores a word at the address in a source register provided there exists a load reservation on that memory address. It writes zero to the destination register if the store succeeded, or a nonzero error code otherwise.
An obvious question is: Why does RV32A have two ways to perform atomic operations? The answer is that there are two quite distinct use cases.
Programming language developers assume the underlying architecture can perform an atomic compare-and-swap operation: Compare a register value to a value in memory ad- dressed by another register, and if they are equal, then swap a third register value with the one in memory. They make that assumption because it is a universal synchronization primitive, in that any other single-word synchronization operation can be synthesized from compare- and-swap [Herlihy 1991].
While that is powerful argument for adding such an instruction to an ISA, it requires three source registers in one instruction. Alas, going from two to three source operands would complicate the integer datapath, control, and the instruction format. (The three source operands of RV32FD’s multiply-add instructions affect the floating-point datapath, not the integer datapath.) Fortunately, load reserved and store conditional have only two source registers and can implement atomic compare and swap (see top half of Figure 6.3).
The rationale for also having AMO instructions is that they scale better to large multipro- cessor systems than load reserved and store conditional. They can also be used to implement reduction operations efficiently. AMOs are useful as well for communicating with I/O de- vices, because they perform a read and a write in a single atomic bus transaction. This atomicity can both simplify device drivers and improve I/O performance. The bottom half of Figure 6.3 shows how to write a critical section using atomic swap.
AMOs and LR/SC require naturally aligned memory addresses because it
is onerous for hardware to guarantee atomicity across cache-line boundaries.

62
REFERENCES
# Compare-and-swap (CAS) memory word M[a0] using lr/sc.
# Expected old value in a1; desired new value in a2.
0: 100526af
4: 06b69e63
8: 18c526af
c: fe069ae3
lr.w a3,(a0) # Load old value
bne a3,a1,80 # Old value equals a1?
sc.w a3,a2,(a0) # Swap in new value if so
bnez a3,0 # Retry if store failed
… code following successful CAS goes here …
80: # Unsuccessful CAS.
# Critical section guarded by test-and-set spinlock using an AMO.
0: 00100293
4: 0c55232f
8: fe031ee3
li t0,1 # Initialize lock value
amoswap.w.aq t1,t0,(a0) # Attempt to acquire lock
bnez t1,4 # Retry if unsuccessful
… critical section goes here …
20: 0a05202f amoswap.w.rl x0,x0,(a0) # Release lock.
Figure 6.3: Two examples of synchronization. The first uses load reserved/store conditional lr.w,sc.w to implement compare-and-swap, and the second uses an atomic swap amoswap.w to implement a mutex.
Elaboration: Memory consistency models
RISC-V has a relaxed memory consistency model, so other threads may view some memory accesses out of order. Figure 6.2 shows that all RV32A instructions have an acquire bit (aq) and a release bit (rl). An atomic operation with the aq bit set guarantees that other threads will see the AMO in-order with subsequent memory accesses. If the rl bit is set, other threads will see the atomic operation in-order with previous memory accesses. To learn more, [Adve and Gharachorloo 1996] is an excellent tutorial on the topic.
What’s Different? The original MIPS-32 had no mechanism for synchronization, but architects added load reserved / store conditional instructions to a later MIPS ISA.
6.2 Concluding Remarks
RV32A is optional, and a RISC-V processor is simpler without it. However, as Einstein said, everything should be as simple as possible, but no simpler. Many situations require RV32A.
6.3 To Learn More
S. V. Adve and K. Gharachorloo. Shared memory consistency models: A tutorial. Computer, 29(12):66–76, 1996.
M. Herlihy. Wait-free synchronization. ACM Transactions on Programming Languages and Systems, 1991.
D. A. Patterson and J. L. Hennessy. Computer Organization and Design RISC-V Edition: The Hardware Software Interface. Morgan Kaufmann, 2017.

NOTES 63 A.WatermanandK.Asanovic ́,editors. TheRISC-VInstructionSetManual,VolumeI:
User-Level ISA, Version 2.2. May 2017. URL https://riscv.org/specifications/.
Notes
1 http://parlab.eecs.berkeley.edu

7
RV32C: Compressed Instructions
E. F. Schumacher
(1911-1977) wrote this eco- nomics book that advocated human-scale, decentralized, and appropriate technolo- gies. Translated into nu- merous languages, it was named one of the 100 most influential books since World War II.
Small is Beautiful.
7.1 Introduction
—E. F. Schumacher, 1973
Prior ISAs significantly expanded the number of instructions and instruction formats to shrink code size: adding short instructions with two operands instead of three, small immediate fields, and so on. ARM and MIPS invented whole ISAs twice to shrink code: ARM Thumb and Thumb-2 plus MIPS16 and microMIPS. These new ISAs hampered the processor and the compiler and increased the cognitive load on the assembly language programmer.
RV32C takes a novel approach: every short instruction must map to one single standard 32-bit RISC-V instruction. Moreover, only the assembler and linker are aware of the 16- bit instructions, and it is up to them to replace a wide instruction with its narrow cousin. The compiler writer and assembly language programmer can be blissfully oblivious of the RV32C instructions and their formats, except ending up with programs that are smaller than most. Figure 7.1 is a graphical representation of the RV32C extension instruction set.
The RISC-V architects chose the instructions in the RVC extension to obtain good code compression across a range of programs, using three observations to fit them into 16 bits. First, ten popular registers (a0–a5, s0–s1, sp, and ra) are accessed far more than the rest. Second, many instructions overwrite one of their source operands. Third, immediate operands tend to be small, and some instructions favor certain immediates. So, many RV32C instruc- tions can access only the popular registers; some instructions implicitly overwrite a source operand; and almost all immediates are reduced in size, with loads and stores using only unsigned offsets in multiples of the operand size.
Figures 7.3 and 7.4 list the RV32C code for Insertion Sort and DAXPY. We show the RV32C instructions to demonstrate the impact of compression explicitly, but normally these instructions are invisible in the assembly language program. The comments show the equiv- alent 32-bit instructions to the RV32C instructions parenthetically. Appendix A includes the 32-bit RISC-V instruction that corresponds to each 16-bit RV32C instruction.
For example, at address 4 in Insertion Sort in Figure 7.3, the assembler replaced the following 32-bit RV32I instruction:
addi a4,x0,1 # i = 1
with this 16-bit RV32C instruction:

7.1. INTRODUCTION
65
Integer Computation
_
RV32C
c.addimmediate
c.add immediate * 16 to stack pointer
c.add immediate * 4 to stack pointer nondestructive c.subtract
shift left logical
c. shift right arithmetic immediate
shift right logical _
c.and immediate c.or
c.move c.exclusive or
_
c.load upper immediate Loads and Stores
_load _
c. float store word using stack pointer
_
c.float load doubleword using stack pointer
Control transfer
c.branch equal not equal
_
tozero
register
c.jump
c.jump and link
and link _
Other instructions
c.environment break
store
Figure 7.1: Diagram of the RV32C instructions. The immediate fields of the shift instructions and
c.addi4spn are zero extended and sign extended for the other instructions.
c.li a4,1 # (expands to addi a4,x0,1) i = 1
The RV32C load immediate instruction is narrower because it must specify only one register and a small immediate. The c.li machine code is only four hexadecimal digits in Figure 7.3, showing that the c.li instruction is indeed 2 bytes long.
Another example is at address 10 in Figure 7.3, where the assembler replaced:
add a2,x0,a3 # a2 is pointer to a[j]
with this 16-bit RV32C instruction:
c.mv a2,a3 # (expands to add a2,x0,a3) a2 is pointer to a[j]
The RV32C move instruction is merely 16 bits long because it specifies only two registers. While the processor designer can’t ignore RV32C, an implementation trick makes them inexpensive: a decoder translates all 16-bit instructions into their equivalent 32-bit version before they execute. Figures 7.6 to 7.8 list the RV32C instruction formats and opcodes that the decoder translates. It is equivalent to only 400 gates when the tiniest 32-bit processor— without any RISC-V extensions—is 8000 gates. If it’s 5% of such a tiny design, the decoder
nearly disappears inside a moderate processor that with caches is order 100,000 gates. What’s Different? There are no byte or halfword instructions in RV32C because other instructions have a bigger influence on code size. The small size advantage of Thumb-2 over RV32C in Figure 1.5 on page 9 is due to the code size savings of Load and Store Multiple on procedure entry and exit. RV32C excludes them to maintain the one-to-one mapping to RV32G instructions, which omits them to reduce implementation complexity for high-end processors. Since Thumb-2 is a separate ISA from ARM-32, but a processor can switch between them, the hardware must have two instruction decoders: one for ARM-32 and one
for Thumb-2. RV32GC is a single ISA, so RISC-V processors need only a single decoder.

66
CHAPTER7. RV32C:COMPRESSEDINSTRUCTIONS
Benchmark
ISA
ARM Thumb-2
microMIPS
x86-32
RV32I+RVC
Insertion Sort
Instructions
18
24
20
19
Bytes
46
56
45
52
DAXPY
Instructions
10
12
16
11
Bytes
28
32
50
28
7.2
Figure 7.2: Instructions and code size for Insertion Sort and DAXPY for compressed ISAs.
Elaboration: Why would architects ever skip RV32C?
Instruction decode can be a bottleneck for superscalar processors that try to fetch several in- structions per clock cycle. Another example is macrofusion, whereby the instruction decoder combines RISC-V instructions together to form more powerful instructions for execution (see Chapter 1). A mix of 16-bit RV32C and 32-bit RV32I instructions can make sophisticated decoding more difficult to complete within the clock cycle of a high-performance implemen- tation.
Comparing RV32GC, Thumb-2, microMIPS, and x86-32
Figure 7.2 summarizes the size of Insertion Sort and DAXPY for these four ISAs.
Of the 19 original RV32I instructions in Insertion Sort, 12 become RV32C, so the code shrinks from 19×4 = 76 bytes to 12×2+7×4 = 52 bytes, saving 24/76 = 32%. DAXPY
shrinks from 11 × 4 = 44 bytes to 8 × 2 + 3 × 4 = 28 bytes, or 16/44 = 36%.
The results for these two small examples are surprisingly in line with Figure 1.5 on page 9 in Chapter 2, which shows that RV32G code is about 37% larger than RV32GC code, for a larger set of much bigger programs. To achieve that level of savings, over half of the
instructions in the programs had to be RV32C instructions.
Elaboration: Is RV32C really unique?
RV32I instructions are indistinguishable in RV32IC. Thumb-2 is actually a separate ISA with 16-bit instructions plus most but not all of ARMv7. For example, Compare and Branch on Zero is in Thumb-2 but not ARMv7, and vice versa for Reverse Subtract with Carry. Nor is microMIPS32 a superset of MIPS32. For example, microMIPS multiplies branch displacements by two but it’s four in MIPS32. RISC-V always multiplies by two.
7.3
Concluding Remarks
I would have written a shorter letter, but I did not have the time.
He was a mathematician who built one of the first mechanical calculators, which led Turing Award laureate Niklaus Wirth to name a programming language after him.
—Blaise Pascal, 1656.
RV32C gives RISC-V one of the smallest code sizes today. You can almost think of them as hardware-assisted pseudoinstructions. However, now the assembler is hiding them from the assembly language programmer and compiler writer rather than, as in Chapter 3,

7.4. TOLEARNMORE 67
expanding the real instruction set with popular operations that make RISC-V code easier to use and to read. Both approaches aid programmer productivity.
We consider RV32C as one of RISC-V’s best examples of a simple, powerful mechanism that improves its cost-performance.
7.4 To Learn More
A.WatermanandK.Asanovic ́,editors. TheRISC-VInstructionSetManual,VolumeI: User-Level ISA, Version 2.2. May 2017. URL https://riscv.org/specifications/.
Notes
1 http://parlab.eecs.berkeley.edu

68 NOTES
# RV32C (19 instructions, 52 bytes)
# a1 is n, a3 points to a[0], a4 is i, a5 is j, a6 is x
0: 00450693 addi a3,a0,4
4: 4705 c.li a4,1
Outer Loop:
6: 00b76363 bltu a4,a1,c
a: 8082 c.ret
Continue Outer Loop:
c: 0006a803 lw a6,0(a3)
10: 8636 c.mv a2,a3
12: 87ba c.mv a5,a4
#a3 is pointer to a[i]
# (expands to addi a4,x0,1) i = 1
# if i < n, jump to Continue Outer loop # (expands to jalr x0,ra,0) return from function #x=a[i] # (expands to add a2,x0,a3) a2 is pointer to a[j] # (expands to add a5,x0,a4) j = i InnerLoop: 14: ffc62883 lw 18: 01185763 ble 1c: 01162023 sw a7,-4(a2) # a7 = a[j-1] a7,a6,26 # if a[j-1] <= a[i], jump to Exit InnerLoop a7,0(a2) # a[j] = a[j-1] 20: 17fd 22: 1671 24: fbe5 c.addi a5,-1 c.addi a2,-4 c.bnez a5,14 # (expands to addi a5,a5,-1) j-- # (expands to addi a2,a2,-4)decr a2 to point to a[j] # (expands to bne a5,x0,14)if j!=0,jump to InnerLoop # (expands to slli a5,a5,0x2) multiply a5 by 4 # (expands to add a5,a5,a0)a5 = byte address of a[j] #a[j]=x # (expands to addi a4,a4,1) i++ # (expands to addi a3,a3,4) incr a3 to point to a[i] # (expands to jal x0,6) jump to Outer Loop Exit InnerLoop: c.slli a5,0x2 c.add a5,a0 26: 078a 28: 97aa 2a: 0107a023 sw a6,0(a5) 2e: 0705 30: 0691 32: bfd1 c.addi a4,1 c.addi a3,4 c.j 6 Figure7.3:RV32CcodeforInsertionSort. Thetwelve16-bitinstructionsmakethecode32%smaller.The width of each instruction is evident by the number of hexadecimal characters in the second column. The RV32C instructions (starting with c.) are shown explicitly in this example, but normally assembly language programmers and compilers cannot see them. NOTES 69 # RV32DC (11 instructions, 28 bytes) # a0 is n, a1 is pointer to x[0], a2 is pointer to y[0], fa0 is a 0: cd09 2: 050e 4: 9532 Loop: 6: 2218 c.beqz a0,1a c.slli a0,a0,0x3 c.add a0,a2 c.fld fa4,0(a2) c.fld fa5,0(a1) c.addi a2,8 c.addi a1,8 # (expands to beq a0,x0,1a) if n==0, jump to Exit # (expands to slli a0,a0,0x3) a0 = n*8 # (expands to add a0,a0,a2) a0 = address of x[n] # (expands to fld fa4,0(a2) ) fa5 = x[] # (expands to fld fa5,0(a1) ) fa4 = y[] # (expands to addi a2,a2,8) a2++ (incr. ptr to y) # (expands to addi a1,a1,8) a1++ (incr. ptr to x) 8: 219c a: 0621 c: 05a1 e: 72a7f7c3 fmadd.d fa5,fa5,fa0,fa4 # fa5 = a*x[i] + y[i] 12: fef63c27 fsd fa5,-8(a2) 16: fea618e3 bne a2,a0,6 Exit: 1a: 8082 ret # y[i] = a*x[i] + y[i] # if i != n, jump to Loop # (expands to jalr x0,ra,0) return from function Figure 7.4: RV32DC code for DAXPY. The eight 16-bit instructions shrink the code by 36%. The width of each instruction is evident by the number of hexadecimal characters in the second column. The RV32C instructions (starting with c.) are shown explicitly in this example, but normally they are invisible to the assembly language programmer and compiler. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 000 nzimm[5] 0 nzimm[4:0] 01 000 nzimm[5] rs1/rd̸=0 nzimm[4:0] 01 001 imm[11|4|9:8|10|6|7|3:1|5] 01 010 imm[5] rd̸=0 imm[4:0] 01 011 nzimm[9] 2 nzimm[4|6|8:7|5] 01 011 nzimm[17] rd̸={0, 2} nzimm[16:12] 01 100 nzuimm[5] 00 rs1′ /rd′ nzuimm[4:0] 01 100 nzuimm[5] 01 rs1′ /rd′ nzuimm[4:0] 01 100 imm[5] 10 rs1′ /rd′ imm[4:0] 01 100 0 11 rs1′ /rd′ 00 rs2′ 01 100 0 11 rs1′ /rd′ 01 rs2′ 01 100 0 11 rs1′ /rd′ 10 rs2′ 01 100 0 11 rs1′ /rd′ 11 rs2′ 01 101 imm[11|4|9:8|10|6|7|3:1|5] 01 110 imm[8|4:3] rs1′ imm[7:6|2:1|5] 01 111 imm[8|4:3] rs1′ imm[7:6|2:1|5] 01 CI c.nop CI c.addi CJ c.jal CI c.li CI c.addi16sp CI c.lui CI c.srli CI c.srai CI c.andi CR c.sub CR c.xor CR c.or CR c.and CJ c.j CB c.beqz CB c.bnez Figure 7.5: RV32C opcode map (bits[1 : 0] = 01) lists layout, opcodes, format, and names. rd’, rs1’, and rs2’ refer to the 10 popular registers a0–a5, s0–s1, sp, and ra. (Table 12.5 of Waterman and Asanovic ́ 2017] is the basis of this figure.) 70 NOTES 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 000 0 0 00 000 nzuimm[5:4|9:6|2|3] rd′ 00 001 uimm[5:3] rs1′ uimm[7:6] rd′ 00 010 uimm[5:3] rs1′ uimm[2|6] rd′ 00 011 uimm[5:3] rs1′ uimm[2|6] rd′ 00 101 uimm[5:3] rs1′ uimm[7:6] rs2′ 00 110 uimm[5:3] rs1′ uimm[2|6] rs2′ 00 111 uimm[5:3] rs1′ uimm[2|6] rs2′ 00 CIW Illegal instruction CIW c.addi4spn CL c.fld CL c.lw CL c.flw CL c.fsd CL c.sw CL c.fsw Figure 7.6: RV32C opcode map (bits[1 : 0] = 00) lists layout, opcodes, format, and names. rd’, rs1’, and rs2’ refer to the 10 popular registers a0–a5, s0–s1, sp, and ra. (Table 12.4 of Waterman and Asanovic ́ 2017] is the basis of this figure.) 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 000 nzuimm[5] rs1/rd̸=0 nzuimm[4:0] 10 000 0 rs1/rd̸=0 0 10 001 uimm[5] rd uimm[4:3|8:6] 10 010 uimm[5] rd̸=0 uimm[4:2|7:6] 10 011 uimm[5] rd uimm[4:2|7:6] 10 100 0 rs1̸=0 0 10 100 0 rd̸=0 rs2̸=0 10 100 1 0 0 10 100 1 rs1̸=0 0 10 100 1 rs1/rd̸=0 rs2̸=0 10 101 uimm[5:3|8:6] rs2 10 110 uimm[5:2|7:6] rs2 10 111 uimm[5:2|7:6] rs2 10 CI c.slli CI c.slli64 CSS c.fldsp CSS c.lwsp CSS c.flwsp CJ c.jr CR c.mv CI c.ebreak CJ c.jalr CR c.add CSS c.fsdsp CSS c.swsp CSS c.fswsp Figure 7.7: RV32C opcode map (bits[1 : 0] = 10) lists layout, opcodes, format, and names. (Table 12.6 of Waterman and Asanovic ́ 2017] is the basis of this figure.) Format CR CI CSS CIW CL CS CB CJ Meaning Register Immediate Stack-relative Store Wide Immediate Load Store Branch Jump 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 funct4 rd/rs1 rs2 op funct3 imm rd/rs1 imm op funct3 imm rs2 op funct3 imm rd′ op funct3 imm rs1′ imm rd′ op funct3 imm rs1′ imm rs2′ op funct3 offset rs1′ offset op funct3 jump target op Figure 7.8: Compressed 16-bit RVC instruction formats. rd’, rs1’, and rs2’ refer to the 10 popular registers a0–a5, s0–s1, sp, and ra. (Table 12.1 of Waterman and Asanovic ́ 2017] is the basis of this figure.) NOTES 71 8 RV32V: Vector I’m all for simplicity. If it’s very complicated I can’t understand it. 8.1 Introduction —Seymour Cray Seymour Cray (1925- 1996) was architect of the Cray-1 in 1976, the first commercially successful supercomputer using a vector architecture. The Cray-1 was a gem; it was the world’s fastest computer even without using the vector instructions. This chapter focuses on data-level parallelism, where there is plenty of data that the desired application can compute on concurrently. Arrays are a popular example. While fundamental to scientific applications, multimedia programs use arrays as well. The former uses single- and double-precision float-point data and the latter often uses 8- and 16-bit integer data. The best known architecture for data-level parallelism is Single Instruction Multiple Data (SIMD). SIMD first became popular by partitioning 64-bit registers into many 8-, 16-, or 32- bit pieces and then computing on them in parallel. The opcode supplied the data width and the operation. Data transfers are simply loads and stores of a single (wide) SIMD register. The first step of partitioning existing 64-bit registers is tempting because it is straightfor- ward. To make SIMD faster, architects subsequently widen the registers to compute more partitions concurrently. Because the SIMD ISAs belong to the incremental school of de- sign, and the opcode specifies the data width, expanding the SIMD registers also expands the SIMD instruction set. Each subsequent step of doubling the width of SIMD registers and the number of SIMD instructions leads ISAs down the path of escalating complexity, which is borne by processor designers, compiler writers, and assembly language programmers. An older and, in our opinion, more elegant alternative to exploit data-level parallelism is the vector architecture. This chapter provides our rationale for using vectors instead of SIMD in RISC-V. Vector computers gather objects from main memory and put them into long, sequential vector registers. Pipelined execution units compute very efficiently on these vector registers. Vector architectures then scatter the results back from the vector registers to main memory. The size of the vector registers is determined by the implementation, rather than baked into the opcode, as with SIMD. As we shall see, separating the vector length and maximum op- erations per clock cycle from the instruction encoding is the crux of the vector architecture: the vector microarchitect can flexibly design the data-parallel hardware without affecting the programmer, and the programmer can take advantage of longer vectors without rewriting the code. In addition, vector architectures have many fewer instructions than SIMD architectures. Moreover, vector architectures have well-established compiler technology, unlike SIMD. The Intel Multimedia Extensions (MMX) in 1997 made SIMD popular. They were embraced and expanded via Streaming SIMD Extensions (SSE) in 1999 and Advanced Vector Extensions (AVX) in 2010. MMX fame was fueled by an Intel ad campaign showing disco- dancing workers of a semiconductor line clad in technicolor clean suits (https://www.youtube.com/ watch?v=paU16B-bZEA). 8.2. VECTORCOMPUTATIONINSTRUCTIONS 73 Computation RV32V add multiply multiply high and .vv Load and Store _ strided indexed vector predicate vector vector vector load store or xor minimum maximum convert .vs Comparison equal vectorpredicate notequal .vv and not or exclusive or not .vs greater than or equal subtract divide remainder .vs shift left logical .sv shift right arithmetic shift right logical less than and .vv _ .vvv add .vvs subtract .vsv .vss vector predicate swap Miscellaneous instructions set vector length vector extract.vs vector merge.vv vector select.vv vector set data configuration maximum Figure 8.1: Diagram of the RV32V instructions. Because of dynamic register typing, this instruction diagram also works without change for RV64V in Chapter 9. Vector architectures are rarer than SIMD architectures, so fewer readers know vector ISAs. Thus,thischapterwillhaveamoretutorialflavorthanearlierones.Ifyouwanttodig deeper into vector architectures, read Chapter 4 and Appendix G of [Hennessy and Patterson 2011]. RV32V also has novel features that simplify the ISA, which requires more explanation even if you already are familiar with vector architectures. 8.2 Vector Computation Instructions Figure 8.1 is a graphical representation of the RV32V extension instruction set. The RV32V encoding has not been finalized, so this edition does not include the usual instruction-layout diagram. Virtually every integer and floating-point computation instruction from an earlier chapter has a vector version: Figure 8.1 inherits operations from RV32I, RV32M, RV32F, RV32D, and RV32A. There are several types of each vector instruction depending on whether the source operands are all vectors (.vv suffix) or a vector source operand and a scalar source operand (.vs suffix). A scalar suffix means an x or f register is an operand along with a vector register (v). For example, our DAXPY program (Figure 5.7 on page 55 in Chapter 5) calculates Y = a × X + Y , where X and Y are vectors, and a is a scalar. For vector-scalar operations, the rs1 field specifies the scalar register to be accessed. vector fused negative vector sign injection vector class.v vector move.vv vector square root.v multiply negative _ .vv add and or exclusive or vectoratomicmemoryoperation swap xor .vv .vs minimum Asymmetric operations like subtraction and division offer a third variation of vector in- 74 CHAPTER8. RV32V:VECTOR structions where the first operand is scalar and the second is vector (.sv suffix). Operations like Y = a − X use them. They are superfluous for symmetric operations like addition and multiplication, so those instructions have no .sv version. The fused multiply-add instruc- tions have three operands, so they have the largest combination of vector and scalar options: .vvv, .vvs, .vsv, and .vss. Readers may notice that Figure 8.1 ignores the data type and width of the vector opera- tions. The next section explains why. 8.3 Vector Registers and Dynamic Typing RV32V adds 32 vector registers, whose names start with v, but the number of elements per vector register varies. That number depends on both the width of the operations and on the amount of memory dedicated to vector registers, which is up to the processor designer. For example, if the processor allocated 4096 bytes for vector registers, that is enough for all 32 vector registers to have 16 64-bit elements, 32 32-bit elements, 64 16-bit elements, or 128 8-bit elements. To keep the number of elements flexible in a vector ISA, a vector processor calculates the maximum vector length (mvl) that programs use to run properly on processors with differing amounts of memory for vector registers. The vector length register (vl) sets the number of elements in a vector for a particular operation, which helps programs when a dimension of an array is not a multiple of mvl. We’ll demonstrate mvl, vl, and the eight predicate registers (vpi) in more detail in the following sections. RV32V takes the novel approach of associating the data type and length with the vector registers rather than with the instruction opcodes. A program tags the vector registers with their data type and width before executing the vector computation instructions. Dynamic register typing slashes the number of vector instructions, important because there are often six integer and three floating-point versions of each vector instruction as Figure 8.1 shows. As we shall see in Section 8.9 when we confront the numerous SIMD instructions, a dynamically typed vector architecture reduces the cognitive load on the assembly language programmer and the difficulty of the compiler’s code generator. Another advantage of dynamic typing is that programs can disable unused vector regis- ters. This feature allocates all the vector memory to the enabled vector registers. For example, suppose only two vector registers are enabled, they are type 64-bit floats, and the processor has 1024 bytes of vector register memory. The processor would halve the memory, giving each vector register 512 bytes or 512/8 = 64 elements and therefore set mvl to 64. Thus, mvl is dynamic, but its value is set by the processor and cannot be directly changed by software. The source and destination registers determine the type and size of the operation and the result, so conversions are implicit with dynamic typing. For example, a processor can multi- ply a vector of double-precision floating-point numbers by a single-precision scalar without first having to convert the operands to the same precision. This bonus benefit reduces the total number of vector instructions and the number of instructions executed. The vsetdcfg instruction sets the vector register types. Figure 8.2 shows the vector reg- ister types available to RV32V plus more types for RV64V (see Chapter 9). RV32V requires that vector floating-point operations have the scalar versions also. Thus, you must have at least RV32FV to use the F32 type and RV32FDV to use the F64 type. RV32V introduces a 16-bit floating-point format type F16. If an implementation supports both RV32V and RV32F, then it must support both F16 and F32 formats. 8.4. VECTORLOADSANDSTORES 75 Type Floating Point Signed Integer Unsigned Integer Width Name vetype Name vetype Name vetype 8 bits 16 bits 32 bits 64 bits –– F16 01 101 F32 01 110 F64 01 111 X8 10 100 X16 10 101 X32 10 110 X64 10 111 X8U 11 100 X16U 11 101 X32U 11 110 X64U 11 111 Figure 8.2: RV32V encodings of vector register types. The rightmost three bits of the field show the width of the data, and the two leftmost bits give its type. X64 and U64 are available only for RV64V. F16 and F32 require the RV32F extension and F64 requires RV32F and RV32D. F16 is the IEEE 754-2008 16-bit floating-point format (binary16). Setting vetype to 00000 disables the vector registers. (Table 17.4 of [Waterman and Asanovic ́ 2017] is the basis of this figure.) Elaboration: RV32V can switch context quickly. One reason vector architectures were less popular than SIMD architectures was concern that adding large vector registers would stretch the time to save and restore a program on an interrupt, called a context switch. Dynamic register typing helps. The programmer must tell the processor which vector registers are being used, which means processor needs to save and restore only those registers on a context switch. The RV32V convention is to disable all vector registers when the vector instructions aren’t being used, which means a processor can have the performance benefit of vector registers but pay the extra context switch time only if an interrupt occurs while the vector instructions are executing. Earlier vector architectures had to pay the worst-case context switch cost of saving and restoring all vector registers whenever an interrupt occurred. 8.4 Vector Loads and Stores The easiest case for vector loads and stores is dealing with single-dimension arrays that are stored sequentially in memory. Vector load fills a vector register with data from sequential addresses in memory starting with the address in the vld instruction. The data type associated with the vector register determines the size of the data elements and the vector length register vl sets the number of elements to load. Vector store vst does the inverse operation of vld. For example, if a0 has 1024, and the type of v0 is X32, then vld v0, 0(a0) will gen- erate the addresses 1024, 1028, 1032, 1036, ... until reaching the limit set by vl. For multi-dimension arrays, some accesses will not be sequential. If stored in row major order, sequential column accesses in a two-dimensional array want data elements separated by the size of the row. Vector architectures support these accesses with strided data transfers: vlds and vsts. While one could get the same effect as vld and vst by setting the stride to the size of the element in vlds and vsts, vld and vst guarantee that all accesses will be sequential, which makes it easier to deliver high memory bandwidth. Another reason is that providing vld and vst reduces code size and instructions executed for the common case of unit stride. These instructions specify two source registers, with one giving the starting address and the other specifying the stride in bytes. For example, assume the starting address in a0 was address 1024, and the size of a row in a1 was 64 bytes. vlds v0,a0,a1 would send this sequence of addresses to memory: 1024, 1088 (1024 + 1×64), 1152 (1024 + 2×64), 1216 (1024 + 3×64), and so on until the vector Concern about slow context switch times led Intel to avoid adding registers in the original MMX SIMD extension. It simply reused the existing floating-point registers, which meant no extra context to switch, but a program couldn’t intermix floating-point and multime- dia instructions. Each load and store has a 7-bit unsigned immediate offset that is scaled by the element type in the destination register for loads and the source register for stores. 76 CHAPTER8. RV32V:VECTOR length register vl tells it to stop. The returning data is written into sequential elements of the destination vector register. Thus far, we have assumed that the program is working with dense arrays. To support sparse arrays, vector architectures offer indexed data transfers: vldx and vstx. One source register for these instructions refers to a vector register and the other to a scalar register. The scalar register has the starting address of the sparse array, and each element of the vector register contains the index in bytes of the nonzero elements of the sparse array. Suppose the starting address in a0 was address 1024, and vector register v1 had these byte indices in the first 4 elements: 16, 48, 80, 160. vldx v0,a0,v1 would send this sequence of addresses to memory: 1040 (1024 + 16), 1072 (1024 + 48), 1104 (1024 + 80), 1184 (1024 + 160). It loads the returning data into sequential elements of the destination vector register. We used sparse arrays as our motivation for indexed loads and stores, but there are many other algorithms that access data indirectly via a table of indices. 8.5 Parallelism During Vector Execution While a simple vector processor might execute one vector element at a time, element oper- ations are independent by definition, and so a processor could theoretically compute all of them simultaneously. The widest data for RV32G is 64 bits, and today’s vector processors typically execute two, four, or eight 64-bit elements per clock cycle. Hardware handles the fringe cases when the vector length is not a multiple of the number of the elements executed per clock cycle. Like SIMD, the number of smaller data operations is the ratio of the widths of the narrow data to the wide data. Thus, a vector processor that computes 4 64-bit operations per clock cycle would normally launch 8 32-bit, 16 16-bit, and 32 8-bit operations per clock cycle. In SIMD, the ISA architect determines the maximum number of data parallel operations per clock cycle and the number of elements per register. In contrast, the RV32V processor designer picks both of them without having to change the ISA or the compiler, while every doubling of SIMD register width doubles the number of SIMD instructions and requires changes to the SIMD compilers. This hidden flexibility means the identical RV32V program runs without change on the simplest and most aggressive vector processors. 8.6 Conditional Execution of Vector Operations Some vector computations include if statements. Rather than rely on conditional branches, vector architectures include a mask that suppresses operations on some elements of a vector operation. The predicate instructions in Figure 8.1 perform conditional tests between two vectors or a vector and scalar and writes into each element of the vector mask a 1 if the condition holds or a 0 otherwise. (The vector mask must have the same number of elements as the vector registers.) Any subsequent vector instruction can use that mask, with a 1 in bit i means that element i is changed by vector operations, and a 0 means that element i is unchanged. RV32V provides 8 vector predicate registers (vpi) to act as vector masks. The instruc- tions vpand, vpandn, vpor, vpxor, and vpnot perform logical instructions to combine them together to allow efficient processing of nested conditional statements. RV32V instructions specify either vp0 or vp1 to be the mask that controls a vector oper- ation. To perform a normal operation on all elements, one of those two predicates registers Indexed load is also called gather and indexed store is often named scatter. A program is called vectorizable if most operations are performed by vector instructions. Gather, scatter, and predi- cate instructions increase the number of vectorizable programs. 8.7. MISCELLANEOUSVECTORINSTRUCTIONS 77 must be set to all ones. To swap one of the other six predicate registers quickly into vp0 or vp1, RV32V has the vpswap instruction. The predicate registers are also enabled dynami- cally, and disabling them clears all the predicate registers quickly. For example, suppose all the even-numbered elements of vector register v3 were negative integers and all the odd-numbered elements were positive integers. The result of this code: vplt.vs vp0,v3,x0 # set mask bits when elements of v3 < 0 add.vv,vp0 v0,v1,v2 # change elements of v0 to v1+v2 when true would set all the even bits of vp0 to 1, all the odd bits to 0, and would replace all the even elements of v0 with the sum of the corresponding elements of v1 and v2. The odd elements of v0 would be unchanged. 8.7 Miscellaneous Vector Instructions Adding to the instruction that configures the data types of vector registers mentioned above (vsetdcfg), setvl sets the vector length register (vl) and the destination register with the smaller of the source operand and the maximum vector length (mvl). The reason for picking the minimum is to decide in loops whether the vector code can run at the maximum vector length (mvl) or it must run at a smaller value to cover the remaining elements. Thus, to handle the tail, setvl is executed every loop iteration. RV32V also has three instructions that manipulate elements within a vector register. Vector select (vselect) produces a new result vector by gathering elements from one source data vector at the element locations specified by the second source index vector: # vindices holds values from 0..mvl-1 that select elements from vsrc vselect vdest, vsrc, vindices Thus,ifthefirstfourelementsofv2contain8,0,4,2,thenvselect v0,v1,v2willreplace the zeroth element of v0 with eighth element of v1, the first element of v0 with the zeroth element of v1, the second element of v0 with the fourth element of v1, and the third element of v0 with the second element of v1. Vector merge (vmerge) resembles vector select, but it uses a vector predicate register to choose which of the sources to use. It produces a new result vector by gathering elements from one of two source registers depending on the predicate register. The new element comes from vsrc1 if the predicate vector register element is 0 or from vsrc2 if it is 1: # vp0 bit i determines whether new element i for vdest # comes from vsrc1 (if bit i == 0) or vsrc2 (if bit i == 1) vmerge,vp0 vdest, vsrc1, vsrc2 Thus, if the first four elements of vp0 contain 1, 0, 0, 1, the first four elements of v1 contain 1, 2,3,4,andthefirstfourelementsofv2contain10,20,30,40,thenvmerge,vp0 v0,v1,v2 will make the first four elements of v0 be 10, 2, 3, 40. The vector extract instruction takes elements starting from the middle of one vector and places these at the beginning of a second vector register: # start is scalar reg holding element starting number of vsrc vextract vdest, vsrc, start 78 CHAPTER8. RV32V:VECTOR # a0 is n, a1 is pointer to x[0], a2 is pointer to y[0], fa0 is a 0: li t0, 2<<25 4: vsetdcfg t0 loop: # enable 2 64b Fl.Pt. registers #vl=t0=min(mvl,n) # load vector x #t1=vl*8(inbytes) # load vector y # increment C pointer to x by vl*8 #v1+=v0*fa0(y=a*x+y) #n-=vl(t0) # store Y # increment C pointer to y by vl*8 #repeatifn!=0 # return 8: setvl t0, a0 v0, a1 t1, t0, 3 v1, a2 a1, a1, t1 c: vld 10: slli 14: vld 18: add 1c: vfmaddv1,v0,fa0,v1 20: sub 24: vst 28: add 2c: bnez 30: ret a0, a0, t0 v1, a2 a2, a2, t1 a0, loop Figure 8.3: RV32V code for DAXPY in Figure 5.7. The machine language is missing because the RV32V opcodes are yet to be defined. For example, if vector length vl is 64 and a0 contains 32, then vextract v0,v1,a0 will copy the last 32 elements of v1 into the first 32 elements of v0. The vextract instruction assists reductions by following a recursive-halving approach foranybinaryassociativeoperator. Forexample,tosumalltheelementsofavectorregister, use vector extract to copy the last half of a vector into the first half of another vector register and halve the vector length. Next, add these two vector registers together and repeat the recursive-halving with their sum until vector length equals 1. The result in the zeroth element will be the sum of all the original elements in the vector register. 8.8 Vector Example: DAXPY in RV32V Figure 8.3 shows the RV32V assembly language for DAXPY (Figure 5.7 on page 55 in Chap- ter 5), which we’ll explain a step at a time. RV32V DAXPY starts by enabling the vector registers needed for this function. It re- quires only two vector registers to hold portions of x and y, which are double-precision floating-point numbers each 8 bytes wide. The first instruction creates a constant and the sec- ond writes it to the control status register that configures vector registers (vcfgd) to get two registers of type F64 (see Figure 8.2). By definition, the hardware allocates the configured registers in numerical order, yielding v0 and v1. Let’s assume our RV32V processor has 1024 bytes of memory dedicated to vector reg- isters. The hardware allocates the memory evenly between the two vector registers, which hold double-precision floating-point numbers (8 bytes). Each vector register has 512/8 = 64 elements, so the processor sets the maximum vector length (mvl) for this function to 64. The first instruction in the loop sets the vector length for the following vector instructions. The instruction setvl writes the smaller of the mvl and n into vl and t0. The insight is that if the number of iterations of the loop is larger than n, the fastest the code can crunch the data is 64 values at time, so set vl to mvl. If n is smaller than mvl, then we can’t read or write beyond the end of x and y, so we should compute only on the last n elements in this final The V in RISC-V is also for vector. The RISC-V architects had ex- tensive positive experience with vector architectures and were frustrated that SIMD dominated micro- processors. Hence, the V is for the fifth Berkeley RISC project and because their ISA would highlight vectors. 8.9. COMPARINGRV32V,MIPS-32MSASIMD,ANDX86-32AVXSIMD 79 iteration of the loop. setvl also writes to t0 to help with later loop bookkeeping at location 10. The instruction vld at address c is a vector load from the address of x in scalar register a1. It transfers vl elements of x from memory to v0. The following shift instruction slli multiplies the vector length by the width of the data in bytes (8) for later use in incrementing pointers to x and y. The instruction at address 14 (vld) loads vl elements of y from memory into v1 and the next instruction (add) increments the pointer to x. The instruction at address 1c is the jackpot. vfmadd multiplies vl elements of x (v0) by the scalar a (f0) and adds each product to vl elements of y (v1) and stores those vl sums back into y (v1). All that is to left is store the results in memory and some loop overhead. The instruction at address 20 (sub) decrements n (a0) by vl to record the number of operations completed in this iteration of the loop. The following instruction (vst) stores vl results into y in memory. The instruction at address 28 (add) increments the pointer to y and the following instruction repeats the loop if n (a0) is not zero. If n is zero, the final instruction ret returns to the calling site. The power of vector architecture is that each iteration of this 10-instruction loop launches 3 × 64 = 192 memory accesses and 2 × 64 = 128 floating-point multiplies and additions (assuming that n is at least 64). That averages about 19 memory accesses and 13 operations per instruction. As we shall see in the next section, these ratios for SIMD are an order of magnitude worse. 8.9 Comparing RV32V, MIPS-32 MSA SIMD, and x86-32 AVX SIMD We’ll now see the contrast between how SIMD and vector executes DAXPY. If you tilt your head, you can see SIMD as a restricted vector architecture with short vector registers—eight 8-bit “elements”—but it has no vector length register and no strided or indexed data transfers. MIPS SIMD. Figure 8.5 on page 83 shows the MIPS SIMD Architecture (MSA) version of DAXPY. Each MSA SIMD instruction can operate on two floating-point numbers since the MSA registers are 128 bits wide. Unlike RV32V, because there is no vector length register, MSA requires extra bookkeep- ing instructions to check for problem values of n. When n is odd, there is extra code to compute a single floating-point multiply-add since MSA must operate on pairs of operands. That code is found in locations 3c to 4c in Figure 8.5. In the unlikely but possible case when n is zero, the branch at location 10 will skip the main computation loop. If it doesn’t branch around the loop, the instruction at location 18 (splati.d) puts copies of a in both halves of the SIMD register w2. To add scalar data in SIMD, we need to replicate it to be as wide as the SIMD register. Inside the loop, the ld.d instruction at location 1c loads two elements of y into SIMD register w0 and then increments the pointer to y. It then does the a load of two elements of x into the SIMD register w1. The following instruction at location 28 increments the pointer to x. The payoff multiply-add instruction at location 2c is next. The (delayed) branch at the end of the loop tests to see if the pointer to y has been incremented beyond the last even element of y. If it hasn’t, the loop repeats. The SIMD store in the delay slot at address 34 writes the result to two elements of y. Vector architectures without setvl have extra strip-mining code tosetvltothelastn elements of the loop and to check if n is initially zero. ARM-32 has a SIMD extension called NEON but it doesn’t support double-precision floating-point instructions, so it doesn’t help DAXPY. Such bookkeeping code is considered part ofstrip miningin vector architectures. As the caption of Figure 8.5 explains, the vector length register vl renders such SIMD bookkeeping code moot for RV32V. Traditional vector architectures need extra code to handle the corner case of n = 0. RV32V just makes vector instructions act like nops whenn=0. 80 CHAPTER8. RV32V:VECTOR ISA MIPS-32 MSA x86-32 AVX2 RV32FDV Instructions (static) 22 29 13 Bytes (static) 88 92 52 Instructions per Main Loop 7 6 10 Results per Main Loop 2 4 64 Instructions (dynamic, n=1000) 3511 1517 163 Figure 8.4: Number of instructions and code size of DAXPY for vector ISAs. It lists number of instructions total (static), code size, number of instructions and results per loop, and number of instructions executed (n = 1000). microMIPS with MSA shrinks code size to 64 bytes and RV32FDCV reduces it to 40 bytes. After the main loop terminates, the code checks to see if n is odd. If so, it performs the last multiply-add using scalar instructions from Chapter 5. The final instruction returns to the calling site. The 7-instruction loop at the heart of the MIPS MSA DAXPY code does 6 double- precision memory accesses and 4 floating-point multiplies and additions. The average is about 1 memory access and 0.5 operations per instruction. x86 SIMD. Intel has gone through many generations of SIMD extensions, which we see in the code in Figure 8.6 on page 84. The SSE expansion to 128-bit SIMD led to the xmm registers and instructions that can use them, and the expansion to 256-bit SIMD as part of AVX created the ymm registers and their instructions. The first group of instructions at addresses 0 to 25 load the variables from memory, make four copies of a in a 256-bit ymm registers, and tests to ensure n is at least 4 before entering the main loop. It uses two SSE and one AVX instructions. (The caption of Figure 8.6 explains how in more detail.) The main loop does the heart of the DAXPY computation. The AVX instruction vmovapd at address 27 loads 4 elements of x into ymm0. The AVX instruction vfmadd213pd at address 2c multiplies 4 copies of a (ymm2) times 4 elements of x (ymm0), adds 4 elements of y (in memory at address ecx+edx*8), and puts the 4 sums into ymm0. The following AVX instruc- tion at address 32, vmovapd, stores the 4 results into y. The next three instructions increment counters and repeat the loop if needed. As was the case for MIPS MSA, the “fringe” code between addresses 3e and 57 deals with the cases when n is not a multiple of 4. It relies on three SSE instructions. The 6 instructions of the main loop in the x86-32 AVX2 DAXPY code do 12 double- precision memory accesses and 8 floating-point multiplies and additions. They average 2 memory accesses and about 1 operation per instruction. Elaboration: The Illiac IV was the first to show the difficulty of compiling for SIMD. With 64 parallel 64-bit floating-point units (FPUs), the Illiac IV was planned to have more than 1 million logic gates before Moore published his law. Its architect originally predicted 1000 million floating-point operations per second (MFLOPS), but actual performance was 15 MFLOPS at best. Costs escalated from the $8M estimated in 1966 to $31M by 1972, despite the construction of only 64 of the planned 256 FPUs. The project started in 1965 but took until 1976 to run its first real application, the year the Cray-1 was unveiled. Perhaps the most infamous supercomputer, it made a top 10 list of engineering disasters [Falk 1976]. 8.10. CONCLUDINGREMARKS 81 8.10 Concluding Remarks If the code is vectorizable, the best architecture is vector. —Jim Smith, keynote speech, International Symposium on Computer Architecture, 1994 Figure 8.4 summarizes the number of instructions and number of bytes in DAXPY of pro- grams for RV32IFDV, MIPS-32 MSA, and x86-32 AVX2. The SIMD computation code is dwarfed by the bookkeeping code. Two-thirds to three-fourths of the code for MIPS-32 MSA and x86-32 AVX2 is SIMD overhead, either to prepare the data for the main SIMD loop or to handle the fringe elements when n is not a multiple of the number of floating-point numbers in a SIMD register. RV32V code in Figure 8.3 doesn’t need such bookkeeping code, which halves the number of instructions. Unlike SIMD, it has a vector length register, which makes the vector instruc- tionsworkatanyvalueofn. YoumightthinkRV32Vwouldhaveaproblemwhennis0.It doesn’t because RV32V vector instructions leave everything unchanged when vl = 0. However, the most significant difference between SIMD and vector processing is not the static code size. The SIMD instructions execute 10 to 20 times more instructions than RV32V because each SIMD loop does only 2 or 4 elements instead of 64 in the vector case. The extra instruction fetches and instruction decodes means higher energy to perform the same task. Comparing the results in Figure 8.4 to the scalar versions of DAXPY in Figure 5.8 on page 29 in Chapter 5, we see that SIMD roughly doubles the size of the code in instructions and bytes, but the main loop is the same size. The reduction in the dynamic number of instructions executed is a factor of 2 or 4, depending on the width of the SIMD registers. However, the RV32V vector code size increases by a factor of 1.2 (with the main loop 1.4X) but the dynamic instruction count is a factor of 43 smaller! While dynamic instruction count is a large difference, in our view that is the second most significant disparity between SIMD and vector. Lacking a vector length register explodes the number of instructions as well as the bookkeeping code. ISAs like MIPS-32 and x86-32 that follow the incrementalist doctrine must duplicate all the old SIMD instructions defined for narrower SIMD registers every time they double the SIMD width. Surely, hundreds of MIPS- 32 and x86-32 instructions were created over many generations of SIMD ISAs and hundreds more are in their future. The cognitive load on the assembly language programmer of this brute force approach to ISA evolution must be overwhelming. How can one remember what vfmadd213pd means and when to use it? In comparison, RV32V code is unaffected by the size of the memory for vector registers. Not only is RV32V unchanged if vector memory size expands, you don’t even have to re- compile. Since the processor supplies the value of maximum vector length mvl, the code in Figure 8.3 is untouched whether a processor raises the vector memory from 1024 bytes to, say, 4096 bytes, or drops it to 256 bytes. Unlike SIMD, where the ISA dictates the required hardware—and changing the ISA means changing the compiler—the RV32V ISA allows processor designers to choose the resources for data parallelism for their application without affecting the programmer or com- piler. One can argue that SIMD violates the ISA design principle from Chapter 1 of isolating the architecture from implementation. We think the high contrast in cost-energy-performance, complexity, and ease of program- ming between the modular vector approach of RV32V and the incrementalist SIMD architec- tures of ARM-32, MIPS-32, and x86-32 might be the most persuasive argument for RISC-V. 82 NOTES 8.11 To Learn More H. Falk. What went wrong V: Reaching for a gigaflop: The fate of the famed Illiac IV was shaped by both research brilliance and real-world disasters. IEEE spectrum, 13(10):65–70, 1976. J. L. Hennessy and D. A. Patterson. Computer architecture: a quantitative approach. Else- vier, 2011. A.WatermanandK.Asanovic ́,editors. TheRISC-VInstructionSetManual,VolumeI: User-Level ISA, Version 2.2. May 2017. URL https://riscv.org/specifications/. Notes 1 http://parlab.eecs.berkeley.edu NOTES 83 # a0 is n, a2 is pointer to x[0], a3 is pointer to y[0], $w13 is a 00000000 :
0: 2405fffe li
4: 00852824 and
8: 000540c0 sll
c: 00e81821 addu
a1,-2
a1,a0,a1
t0,a1,0x3
v1,a3,t0
a3,v1,38
v0,a2
# a1 = floor(n/2)*2 (mask bit 0)
# t0 = byte address of a1
# v1 = &y[a1]
# if y==&y[a1] goto Fringe (t0==0 so n is 0 | 1)
# (delay slot) v0 = &x[0]
# w2 = fill SIMD register with copies of a
# w0 = 2 elements of y
# increment C pointer to y by 2 Fl.Pt. numbers # w1 = 2 elements of x
# increment C pointer to x by 2 Fl.Pt. numbers # w0 = w0 + w1 * w2
#if(endofy!=ptrto y) go to Loop
# (delay slot) store 2 elts of y
10: 10e30009 beq
14: 00c01025 move
18: 78786899 splati.d $w2,$w13[0]
Loop:
1c: 78003823 ld.d
20: 24e70010 addiu
24: 78001063 ld.d
28: 24420010 addiu
2c: 7922081b fmadd.d $w0,$w1,$w2
30: 1467fffa bne
34: 7bfe3827 st.d
Fringe:
38: 10a40005 beq
3c: 00c83021 addu
40: d4610000 ldc1
44: d4c00000 ldc1
48: 4c206b61 madd.d
4c: f46d0000 sdc1
Done:
50: 03e00008 jr
54: 00000000 nop
v1,a3,1c
$w0,-16(a3)
$w0,0(a3)
a3,a3,16
$w1,0(v0)
v0,v0,16
# if (n is even) goto Done
# (delay slot) a2 = &x[n-1]
# f1 = y[n-1]
# f0 = x[n-1]
a1,a0,50
a2,a2,t0
$f1,0(v1)
$f0,0(a2)
$f13,$f1,$f13,$f0 # f13 = f1 + f0 * f13 (muladd if n is odd)
$f13,0(v1) # y[n-1] = f13 (store odd result)
ra # return
# (delay slot)
Figure 8.5: MIPS-32 MSA code for DAXPY in Figure 5.7. The bookkeeping overhead of SIMD is evident when comparing this code to the RV32V code in Figure 8.3. The first part of the MIPS MSA code (addresses 0 to 18) duplicate the scalar variable a in a SIMD register and to check to ensure n is at least 2 before entering the main loop. The third part of the MIPS MSA code (addresses 38 to 4c) handle the fringe case when n is not a multiple of 2. Such bookkeeping code is unneeded in RV32V because the vector length register vl and the setvl instruction lets the loop work for all values of n, whether odd or even.

84 NOTES
# eax is i, n is esi, a is xmm1, pointer to x[0] is ebx, pointer to y[0] is ecx
00000000 :
0: 56
1: 53
2: 8b 74 24 0c
6: 8b 5c 24 18
a: c5 fb 10 4c 24 10 vmovsd xmm1,[esp+0x10] # xmm1 = a
4d: c5 fb 11 04 c1
52: 83 c0 01
55: 39 c6
57: 75 e9
Done: 59: 5b
5a: 5e 5b: c3
vmovsd [ecx+eax*8],xmm0 # store into element of y
add eax,0x1 # increment Fringe count
cmp esi,eax # compare Loop and Fringe counts
jne 42 # repeat FringeLoop if != 0
pop ebx # function epilogue
pop esi
ret
push esi
push ebx
mov esi,[esp+0xc] # esi = n
mov ebx,[esp+0x18] # ebx = x
mov ecx,[esp+0x1c] # ecx = y
vmovddup xmm2,xmm1 # xmm2 = {a,a}
mov eax,esi
and eax,0xfffffffc # eax = floor(n/4)*4
10: 8b 4c 24 1c
14: c5 fb 12 d1
18: 89 f0
1a: 83 e0 fc
1d: c4 e3 6d 18 d2 01 vinsertf128 ymm2,ymm2,xmm2,0x1 # ymm2 = {a,a,a,a}
23: 74 19
25: 31 d2
Loop:
je 3e #ifn<4gotoFringe xor edx,edx # edx = 0 vmovapd ymm0,[ebx+edx*8] # load 4 elements of x 27: c5 fd 28 04 d3 2c: c4 e2 ed a8 04 d1 vfmadd213pd ymm0,ymm2,[ecx+edx*8] # 4 mul adds 32: c5 fd 29 04 d1 37: 83 c2 04 3a: 39 c2 3c: 72 e9 Fringe: 3e: 39 c6 40: 76 17 FringeLoop: 42: c5 fb 10 04 c3 47: c4 e2 f1 a9 04 c1 vfmadd213sd xmm0,xmm1,[ecx+eax*8] # 1 mul add vmovapd [ecx+edx*8],ymm0 # store into 4 elements of y add edx,0x4 cmp edx,eax jb 27 cmp esi,eax jbe 59 # compare to n # repeat loop if < n # any fringe elements? # if (n mod 4) == 0 goto Done vmovsd xmm0,[ebx+eax*8] # load element of x Figure 8.6: x86-32 AVX2 code for DAXPY in Figure 5.7. The SSE instruction vmovsd at address a loads a into half of the 128-bit xmm1 register. The SSE instruction vmovddup at address 14 duplicates a into both halves of xmm1 for later SIMD computation. The AVX instruction vinsertf128 at address 1d makes four copies of a in ymm2 starting from the two copies of a in xmm1. The three AVX instructions at addresses 42 to 4d (vmovsd, vfmadd213sd, vmovsd) handle when mod(n,4) ̸= 0. They perform the DAXPY computation one element at a time, with the loop repeating until the function has performed exactly n multiple-add operations. Once again, such code is unnecessary for RV32V because the vector length register vl and the setvl instruction makes the loop work for any value of n. NOTES 85 9 RV64: 64-bit Address Instructions There is only one mistake that can be made in computer design that is difficult to recover from—not having enough address bits for memory addressing and memory management. —C. Gordon Bell, 1976 9.1 Introduction Figures 9.1 to 9.4 shows graphical representations of the RV64G versions of the RV32G instructions. These figures illustrate the small increase in the number of instructions to switch to a 64-bit ISA in RISC-V. The ISAs typically add only a few word, doubleword, or long versions of the 32-bit instructions and expand all the registers, including the PC, to 64 bits. Thus, sub in RV64I subtracts two 64-bit numbers rather than two 32-bit numbers as in RV32I. RV64 is a close but actually different ISA than RV32; it adds a few instructions and the base instructions do slightly different things. For example, Insertion Sort for RV64I in Figure 9.8 is quite near the code for RV32I in Figure 2.8 on page 27 in Chapter 2. It is the same number of instructions and the same number of bytes. The only changes are that the load and store word instructions become load and store doublewords, and the address increment goes from 4 for words (4 bytes) to 8 for doublewords (8 bytes). Figure 9.5 lists the opcodes of the RV64GC instructions in Figures 9.1 to 9.4. Despite RV64I having 64-bit addresses and a default data size of 64 bits, 32-bit words are valid data types in programs. Hence, RV64I needs to support words just as RV32I needs to support bytes and halfwords. More specifically, since registers are now 64 bits wide, RV64I adds word versions of addition and subtraction: addw, addiw, subw. They truncate their results to 32 bits and write the sign-extended result to the destination register. RV64I also includes word versions of the shift instructions to get 32-bit shift result instead of a 64-bit shift result: sllw, slliw, srlw, srliw, sraw, sraiw. To do 64-bit data transfers, it has load and store doubleword: ld, sd. Finally, just as there are unsigned versions of load byte and load halfword in RV32I, RV64I must have an unsigned version of load word: lwu. For similar reasons, RV64M needs to add word versions of multiply, divide, and remain- der: mulw, divw, divuw, remw, remuw. To allow the programmer to synchronize on both words and doublewords, RV64A adds doubleword versions of all 11 of its instructions. C. Gordon Bell (1934-) was one of the lead archi- tects of two of the most popular minicomputer ar- chitectures of their day: the Digital Equipment Cor- poration PDP-11 (16-bit address), which was an- nounced in 1970, and its successor seven years later, the Digital Equipment Corporation 32-bit address VAX-11 (Virtual Address eXtension). 9.1. INTRODUCTION 87 Integer Computation __ Loads and Stores byte load halfword store word doubleword byte load halfword unsigned word Miscellaneous instructions fence loads & stores fence.instruction & data RV64I add immediate word _ subtract word and or exclusive or shift left logical shift right arithmetic shift right logical load upper immediate add upper immediate to pc set less than _ _ immediate unsigned Control transfer branch equal not equal branch greater than or equal _ _ immediate _ _ immediate word environment break call control status register read & clear bit read & set bit read & write _ immediate less than jump and link _ register unsigned Figure 9.1: Diagram of the RV64I instructions. The underlined letters are concatenated from left to right to form RV64I instructions. The dimmed portion are the old RV64I instructions extended to 64-bit registers and the dark (red) portion are the new instructions for RV64I. RV64M RV64A add and or swap atomic memory operation xor maximum _ multiply word multiply high divide remainder _ unsigned signed unsigned .word .doubleword _unsigned _word maximum unsigned minimum minimum unsigned .word .doubleword load reserved store conditional Figure 9.2: Diagrams of the RV64M and RV64A instructions. 88 CHAPTER 9. RV64: 64-BIT ADDRESS INSTRUCTIONS RV64F and RV64D Floating-Point Computation Load and Store float load word store doubleword Conversion float convert to .single from .double _ float add subtract multiply divide square root minimum maximum .single .double .word _unsigned .long floatconvertto .word float convert to .single from .double float convert to .double from .single Other instructions _ negative exclusive or float _ multiply add .single negative subtract .double float move to .single from .x register .double from .single .long unsigned .double float move to .x register from Comparison .single .double .single .double compare float equals less than less than or equals .single .double float sign injection floatclassify .single .double Figure 9.3: Diagram of the RV64F and RV64D instructions. RV64C Integer Computation Control transfer c.branch c.jump c.jump c.add _ c.add immediate * 16 to stack pointer _ immediate word equal not equal _ and link _ and link to zero c.add immediate * 4 to stack pointer nondestructive _ c.subtract word register shift left logical c. shift right arithmetic immediate Other instructions shift right logical _ c.and immediate c.or c.move c.exclusive or _ c.load upper immediate Loads and Stores _ load word c. float store doubleword c.environment break _ using stack pointer c.float load doubleword _using stack pointer store Figure 9.4: Diagram of the RV64C instructions. 9.1. INTRODUCTION 89 31 25 24 20 19 15 14 12 11 7 6 0 imm[11:0] rs1 110 rd 0000011 imm[11:0] rs1 011 rd 0000011 imm[11:5] rs2 rs1 011 imm[4:0] 0100011 000000 shamt rs1 001 rd 0010011 000000 shamt rs1 101 rd 0010011 010000 shamt rs1 101 rd 0010011 imm[11:0] rs1 000 rd 0011011 0000000 shamt rs1 001 rd 0011011 0000000 shamt rs1 101 rd 0011011 0100000 shamt rs1 101 rd 0011011 0000000 rs2 rs1 000 rd 0111011 0100000 rs2 rs1 000 rd 0111011 0000000 rs2 rs1 001 rd 0111011 0000000 rs2 rs1 101 rd 0111011 0100000 rs2 rs1 101 rd 0111011 RV64M Standard Extension (in addition to RV32M) RV64A Standard Extension (in addition to RV32A) I lwu I ld S sd I slli I srli I srai I addiw I slliw I srliw I sraiw R addw R subw R sllw R srlw R sraw R mulw R divw R divuw R remw R remuw R lr.d R sc.d R amoswap.d R amoadd.d R amoxor.d R amoand.d R amoor.d R amomin.d R amomax.d R amominu.d R amomaxu.d R fcvt.l.s R fcvt.lu.s R fcvt.s.l R fcvt.s.lu R fcvt.l.d R fcvt.lu.d R fmv.x.d R fcvt.d.l R fcvt.d.lu R fmv.d.x 0000001 rs2 rs1 000 rd 0111011 0000001 rs2 rs1 100 rd 0111011 0000001 rs2 rs1 101 rd 0111011 0000001 rs2 rs1 110 rd 0111011 0000001 rs2 rs1 111 rd 0111011 00010 aq rl 00000 rs1 011 rd 0101111 00011 aq rl rs2 rs1 011 rd 0101111 00001 aq rl rs2 rs1 011 rd 0101111 00000 aq rl rs2 rs1 011 rd 0101111 00100 aq rl rs2 rs1 011 rd 0101111 01100 aq rl rs2 rs1 011 rd 0101111 01000 aq rl rs2 rs1 011 rd 0101111 10000 aq rl rs2 rs1 011 rd 0101111 10100 aq rl rs2 rs1 011 rd 0101111 11000 aq rl rs2 rs1 011 rd 0101111 11100 aq rl rs2 rs1 011 rd 0101111 RV64F Standard Extension (in addition to RV32F) RV64D Standard Extension (in addition to RV32D) 1100000 00010 rs1 rm rd 1010011 1100000 00011 rs1 rm rd 1010011 1101000 00010 rs1 rm rd 1010011 1101000 00011 rs1 rm rd 1010011 1100001 00010 rs1 rm rd 1010011 1100001 00011 rs1 rm rd 1010011 1110001 00000 rs1 000 rd 1010011 1101001 00010 rs1 rm rd 1010011 1101001 00011 rs1 rm rd 1010011 1111001 00000 rs1 000 rd 1010011 Figure 9.5: RV64 opcode map of the base instructions and optional extensions. It shows instruction layout, opcodes, format type, and name. (Table 19.2 of [ Waterman and Asanovic ́ 2017] is the basis of this figure.) 90 CHAPTER 9. RV64: 64-BIT ADDRESS INSTRUCTIONS RV64F and RV64D adds integer doublewords to the convert instructions, calling them longs so to prevent confusion with double precision floating-point data: fcvt.l.s, fcvt.l.d, fcvt.lu.s, fcvt.lu.d, fcvt.s.l, fcvt.s.lu, fcvt.d.l, fcvt.d.lu. As the integer x registers are now 64 bits wide, they can now hold dou- ble precision floating-point data, so RV64D adds two floating-point moves: fmv.x.w and fmv.w.x. The one exception to the superset relationship between RV64 and RV32 is the compressed instructions. RV64C replaced a few RV32C instructions, since other instructions shrank code more for 64-bit addresses. RV64C drops the compressed jump and link (c.jal) and the integer and floating-point load and store word instructions (c.lw, c.sw, c.lwsp, c.swsp, c.flw, c.fsw, c.flwsp, and c.fswsp). In their place, RV64C adds the more popular add and subtract word instructions (c.addw, c.addiw, c.subw) and load and store double- word instructions (c.ld, c.sd, c.ldsp, c.sdsp). Elaboration: The RV64 ABIs are lp64, lp64f, and lp64d. lp64 means that the C language data types long and pointer are 64 bits; int is still 32 bits. The suffixes f and d indicate how floating-point arguments are passed, which is the same as for RV32 (see Chapter 3). Elaboration: There is no instruction diagram for RV64V because it exactly matches RV32V due to dynamic register typing. The only change is that the X64 and X64U dynamic register types in Figure 8.2 on page 75 are available in RV64V but not RV32V. 9.2 Comparison to Other 64-bit ISAs using Insertion Sort As Gordon Bell said at the opening of this chapter, the one fatal architecture flaw is running out of address bits. As programs pushed the limits of a 32-bit address space, architects began to make 64-bit address versions of their ISAs [Mashey 2009]. The earliest was MIPS in 1991. It extended all registers and the program counter from 32 to 64 bits and added new 64-bit versions of the MIPS-32 instructions. The MIPS-64 assembly language instructions all begin with the letter “d”, such as daddu or dsll (see Figure 9.10). Programmers can mix MIPS-32 and MIPS-64 instructions in the same program. MIPS-64 dropped the load delay slot from MIPS-32 (the pipeline stalls on a read-after-write dependence). A decade later, it was time for a successor to x86-32. When architects increased the addressing size, they took the opportunity to make a few more improvements in x86-64: • Increased the number of integer registers from 8 to 16 (r8–r15); • Increased the number of SIMD registers from 8 to 16 (xmm8–xmm15); and • Added PC-relative data addressing to better support position-independent code. These improvements smoothed some rough edges of x86-32. You can see the benefits by comparing the x86-32 version of Insertion Sort in Figure 2.11 on page 30 in Chapter 2 to the x86-64 version in Figure 9.11. The newer ISA keeps all the variables in registers rather than having several in memory, which reduces the instruction 9.2. COMPARISONTOOTHER64-BITISASUSINGINSERTIONSORT 91 ISA ARM-64 MIPS-64 x86-64 RV64I RV64I+RV64C Instructions 16 24 15 19 19 Bytes 64 96 46 76 52 Figure 9.6: Number of instructions and code size for Insertion Sort for four ISAs. ARM Thumb-2 and microMIPS are 32-bit address ISAs, so are unavailable for ARM-64 and MIPS-64. count from 20 to 15 instructions. The code size is actually larger by one byte with the newer ISA despite having fewer instructions: 46 versus 45. The reason is that to squeeze in the new opcodes to enable more registers, x86-64 added a prefix byte to identify the new instructions. The average instruction length increases in x86-64 over x86-32. ARM faced the same address problem another decade later. Rather than evolve the old ISA to have 64-bit addresses as did x86-64, they used the opportunity to invent a brand new ISA. Given a fresh start, they changed many of the awkward ARM-32 traits to give them a modern ISA: • Increase the number of integer registers from 15 to 31; • Remove the PC from the set of registers; • Provide a register that’s hardwired to zero for most instructions (r31); • Unlike ARM-32, all ARM-64 data addressing modes work with all data sizes and types; • ARM-64 dropped the load and store multiple instructions of ARM-32; and • ARM-64 omitted the conditional execution option of ARM-32 instructions. It still shares some weaknesses of ARM-32: condition codes for branch, source and desti- nation register fields move in the instruction format, conditional move instructions, complex addressing modes, inconsistent performance counters, and only 32-bit length instructions. ARM-64 can’t switch to the Thumb-2 ISA, as Thumb-2 only works with 32-bit addresses. Unlike RISC-V, ARM decided to take a maximalist approach to ISA design. While cer- tainly a better ISA than ARM-32, it is also bigger. For example, it has more than 1000 instructions and the ARM-64 manual is 3185 pages long [ARM 2015]. Moreover, it is still growing. There have been three expansions of ARM-64 since its announcement a few years ago. The ARM-64 code for Insertion Sort in Figure 9.9 looks closer to the RV64I code or x86-64 code than to the ARM-32 code. For example, with 31 registers, there is no need to save and restore registers from the stack. And since the PC is no longer one of the registers, ARM-64 uses a separate return instruction. Figure 9.6 is a table that summarizes the number of instructions and number of bytes in Insertion Sort for the ISAs. Figures 9.8 to 9.11 show the compiled code for RV64I, ARM-64, MIPS-64, and x86-64. Parenthetical phrases in the comments of these four programs identify the differences between the RV32I versions in Chapter 2 and these RV64I versions. MIPS-64 needs the most instructions, primarily because of the nop instructions of the unfilled delayed branch slots. RV64I needs fewer because of the compare-and-branch in- structions and no delayed branch. While ARM-64 and x86-64 need two compare instructions Intel didn’t invent the x86-64 ISA. When switching to 64-bit ad- dresses, Intel invented a new ISA called Itanium that was incompatible with x86-32. Its competitor for x86-32 processors was locked out of Itanium, so AMD invented a 64-bit version of x86-32 called AMD64. Itanium eventually failed, so Intel was forced to adopt the AMD64 ISA as the 64-bit address suc- cessor of x86-32, which we call x86-64 [Kerner and Padgett 2007]. 92 CHAPTER 9. RV64: 64-BIT ADDRESS INSTRUCTIONS 1.4 1.2 1 1 0.8 0.6 0.4 0.2 0 1.35 1.34 1.23 RISC-V RV64GC (16b & 32b) RISC-V RV64G (32b) ARM-64 (32b) INTEL x86-64 (variable 8b) Figure 9.7: Relative program sizes for RV64G, ARM-64, and x86-64 versus RV64GC. This comparison measures much bigger programs than in Figure 9.6. This graph is the 64-bit address equivalent to the graph of 32-bit ISAs in Figure 1.5 on page 9 in Chapter 2. RV32C code size almost matches to RV64C; it is 1% smaller. There is no Thumb-2 option for ARM-64, so the core of other 64-bit ISAs significantly exceeds the size of RV64GC code. The programs measured were the SPEC CPU2006 benchmarks using the GCC compilers [Waterman 2016]. that are unnecessary for RV64I, their scaling addressing modes avoid address arithmetic in- structions needed in RV64I, giving them the fewest instructions. However, RV64I+RV64C has much smaller code size, as the next section explains. Elaboration: ARM-64, MIPS-64, and x86-64 aren’t the official names. The official names are: ARMv8 is what we call ARM-64, MIPS-IV is MIPS-64, and AMD64 is x86-64 (see the sidebar on the previous page for the history of x86-64). 9.3 Program size Figure 9.7 compares average relative code sizes for RV64, ARM-64, and x86-64. Compare this figure to Figure 1.5 on page 9 in Chapter 1. First, RV32GC code is almost identical in size to RV64GC; it is only 1% smaller. This closeness is also true for RV32I and RV64I. While ARM-64 code is 8% smaller than ARM-32 code, there is no 64-bit address version of Thumb- 2, so all instructions remain 32-bits long. Hence, ARM-64 code is 25% larger than ARM Thumb-2 code. Code for x86-64 is 7% larger than x86-32 code due to adding prefix opcodes to x86-64 instructions to accommodate new operations and the expanded set of registers. RV64GC wins as ARM-64 code is 23% bigger than RV64GC and x86-64 code is 34% bigger than RV64GC. That difference is large enough that either it will improve performance due to lower instruction cache miss rates, or reduce cost by allowing a smaller instruction cache that still provides satisfactory miss rates. Code Size Rela,ve to RV32GC 9.4. CONCLUDINGREMARKS 93 9.4 Concluding Remarks One of the problems of being a pioneer is you always make mistakes, and I never, never want to be a pioneer. It’s always best to come second when you can look at the mistakes the pioneers made. —Seymour Cray, architect of the first supercomputer, 1976 Running out of address bits is the Achilles heel of computer architecture. Many an archi- tecture has died from a wound there. ARM-32 and Thumb-2 remain 32-bit architectures, so they’re no help for big programs. Some ISAs like MIPS-64 and x86-64 survived the transi- tion, but x86-64 is not a paragon of ISA design and the future of MIPS-64 is unclear at the time of this writing. ARM-64 is a new large ISA, and time will tell how successful it will be. RISC-V benefited from designing both the 32-bit and the 64-bit architectures together, whereas older ISAs had to architect them sequentially. Unsurprisingly, the transition between 32-bit and 64-bit is easiest for RISC-V programmers and compiler writers; the RV64I ISA has virtually all RV32I instructions. Indeed, that is why we can list both RV32GCV and RV64GCV in only two pages of the Reference Card. More important, the simultaneous design meant the 64-bit architecture did not have to be squeezed into a cramped 32-bit opcode space. RV64I has plenty of room for optional instruction extensions, particularly RV64C, which makes it the leader in code size. We see the 64-bit architecture as more evidence of RISC-V’s sound design, admittedly easier to achieve if you start 20 years later so that you can borrow the pioneers’ good ideas as well as learn from their mistakes. Elaboration: RV128 RV128 began as an inside joke with the RISC-V architects, simply to show that a 128-bit address ISA was possible. However, warehouse scale computers may soon have more than 264 bytes of semiconductor storage (DRAM and Flash memory), which programmers might want to access as a memory address. There are also proposals to use a 128-bit address to improve security [Woodruff et al. 2014]. The RISC-V manual does specify a full 128-bit ISA called RV128G [Waterman and Asanovic ́ 2017]. The additional instructions are basically the same as needed to go from RV32 to RV64, which Figures 9.1 to 9.4 illustrate. All the registers also grow to 128 bits, and the new RV128 instructions specify either 128-bit versions of some instructions (using Q in the name for quadword) or 64-bit versions of others (using D for in the name doubleword). 9.5 To Learn More I. ARM. Armv8-a architecture reference manual. 2015. M. Kerner and N. Padgett. A history of modern 64-bit computing. Technical report, CS De- partment, University of Washington, Feb 2007. URL http://courses.cs.washington. edu/courses/csep590/06au/projects/history-64-bit.pdf. J. Mashey. The long road to 64 bits. Communications of the ACM, 52(1):45–53, 2009. A. Waterman. Design of the RISC-V Instruction Set Architecture. PhD thesis, EECS Depart- ment, University of California, Berkeley, Jan 2016. URL http://www2.eecs.berkeley. edu/Pubs/TechRpts/2016/EECS-2016-1.html. MIPS is for sale. Imagination Technologies, which bought the MIPS ISA in 2012 for $100M, recently announced that it is for sale; no buyers yet. 94 NOTES A.WatermanandK.Asanovic ́,editors. TheRISC-VInstructionSetManual,VolumeI: User-Level ISA, Version 2.2. May 2017. URL https://riscv.org/specifications/. J. Woodruff, R. N. Watson, D. Chisnall, S. W. Moore, J. Anderson, B. Davis, B. Laurie, P. G. Neumann, R. Norton, and M. Roe. The CHERI capability model: Revisiting RISC in an age of risk. In Computer Architecture (ISCA), 2014 ACM/IEEE 41st International Symposium on, pages 457–468. IEEE, 2014. Notes 1 http://parlab.eecs.berkeley.edu NOTES 95 # RV64I (19 instructions, 76 bytes, or 52 bytes with RV64C) # a1 is n, a3 points to a[0], a4 is i, a5 is j, a6 is x 0: 00850693 addi a3,a0,8 #(8vs4)a3ispointertoa[i] 4: 00100713 li a4,1 #i=1 Outer Loop: 8: 00b76463 bltu a4,a1,10 # if i < n, jump to Continue Outer loop Exit Outer Loop: c: 00008067 ret Continue Outer Loop: 10: 0006b803 ld 14: 00068613 mv 18: 00070793 mv # return from function a6,0(a3) #(ldvslw)x=a[i] a2,a3 # a2 is pointer to a[j] a5,a4 #j=i Inner Loop: 1c: ff863883 ld 20: 01185a63 ble 24: 01163023 sd 28: fff78793 addi a5,a5,-1 # j-- 2c: ff860613 addi a2,a2,-8 # (8 vs 4) decrement a2 to point to a[j] 30: fe0796e3 bnez a5,1c #ifj!=0,jumptoInnerLoop 38: 00f507b3 add a5,a0,a5 3c: 0107b023 sd a6,0(a5) 40: 00170713 addi a4,a4,1 44: 00868693 addi a3,a3,8 48: fc1ff06f j 8 # a5 is now byte address oi a[j] #(sdvssw)a[j]=x # i++ # increment a3 to point to a[i] # jump to Outer Loop # continue outer loop a7,-8(a2) # (ld vs lw, 8 vs 4) a7 = a[j-1] a7,a6,34 # if a[j-1] <= a[i], jump to Exit Inner Loop a7,0(a2) # (sd vs sw) a[j] = a[j-1] Exit Inner Loop: 34: 00379793 slli a5,a5,0x3 # (8 vs 4) multiply a5 by 8 Figure 9.8: RV64I code for Insertion Sort in Figure 2.5. The RV64I assembly language program is very similar to the RV32I assembly language in Figure 2.8 on page 27 in Chapter 2. We list the differences in parentheses in the comments. The size of the data is now 8 bytes instead of 4, so three instructions change the constant 4 to 8. This extra width also stretches two load words (lw) to load doublewords (ld) and two store words (sw) to store doublewords (sd). 96 NOTES # ARM-64 (16 instructions, 64 bytes) # x0 points to a[0], x1 is n, x2 is j, x3 is i, x4 is x 0: d2800023 mov x3, #0x1 Outer Loop: 4: eb01007f cmp x3, x1 8: 54000043 b.cc 10 Exit Outer Loop: 14:aa0303e2 mov x2,x3 Inner Loop: 18: 8b020c05 add x5, x0, x2, lsl #3 1c: f85f80a5 ldur x5, [x5, #-8] 20: eb0400bf cmp x5, x4 24: 5400008d b.le 34 # i = 1 # compare i vs n # if i < n, jump to Continue Outer loop # return from function 10: f8637804 ldr x4, [x0, x3, lsl #3] # (x4 ca r4) vs x = a[i] c: d65f03c0 ret Continue Outer Loop: 28: f8227805 str x5, [x0, x2, lsl #3] # a[j] = a[j-1] 2c: f1000442 subs x2, x2, #0x1 # j-- 30: 54ffff41 b.ne 18 # if j != 0, jump to Inner Loop Exit Inner Loop: 34: f8227804 str x4, [x0, x2, lsl #3] # a[j] = x 38: 91000463 add x3, x3, #0x1 # i++ 3c: 17fffff2 b 4 # jump to Outer Loop Figure9.9:ARM-64codeforInsertionSortinFigure2.5. TheARM-64assemblylanguageprogramis different from to the ARM-32 assembly language in Figure 2.11 on page 30 in Chapter 2 since it is a new instruction set. The registers start with x instead of a. The data addressing modes can shift a register by 3 bits to scale the index to a byte address. With 31 registers, there is no need to save and restore registers from the stack. Since PC is not one of the registers, it uses is a separate return instruction. In fact, the code looks closer to the RV64I code or x86-64 code than to the ARM-32 code. #(x2vsr2)j=i # x5 is pointer to a[j] # x5 = a[j] # compare a[j-1] vs. x # if a[j-1]<=a[i], jump to Exit Inner Loop NOTES 97 # MIPS-64 (24 instructions, 96 bytes) # a1 is n, a3 is pointer to a[0], v0 is j, v1 is i, t0 is x 0: 64860008 daddiu a2,a0,8 # (daddiu vs addiu, 8 vs 4) a2 is pointer to a[i] #i=1 #setoni
mov rcx,[rdi+rdx*8]
mov rax,rdx
# compare i vs. n
# if i >= n, jump to Exit Outer Loop # x = a[i]
#j=i
Inner Loop:
11: 4c 8b 44 c7 f8 mov r8,[rdi+rax*8-0x8] # r8 = a[j-1]
16: 49 39 c8
19: 7e 09
1b: 4c 89 04 c7
1f: 48 ff c8
22: 75 ed
Exit InnerLoop:
24: 48 89 0c c7
28: 48 ff c2
2b: eb d8
Exit Outer Loop:
2d: c3
cmp r8,rcx
jle 24
mov [rdi+rax*8],r8
dec rax
jne 11
mov [rdi+rax*8],rcx
inc rdx
jmp 5
ret
# compare a[j-1] vs. x
# if a[j-1]<=a[i],jump to Exit InnerLoop # a[j] = a[j-1] # j-- # if j != 0, jump to Inner Loop # a[j] = x # i++ # jump to Outer Loop # return from function Figure 9.11: x86-64 code for Insertion Sort in Figure 2.5. The x86-64 assembly language program is quite different from to the x86-32 assembly language in Figure 2.11 on page 30 in Chapter 2. First, unlike RV64I, the wider registers have different names rax, rcx, rdx, rsi, rdi, r8. Second, because x86-64 added 8 more registers, there are now enough to keep all the variables in registers instead of in memory. Third, the x86-64 instructions are longer than for x86-32 since many need to prepend 8-bits or 16-bits to fit the new instructions in the opcode space. For example, incrementing or decrementing a register (inc, dec) takes 1 byte in x86-32 but 3 bytes in x86-64. Hence, while many fewer instructions, x86-64 code size of Insertion Sort is almost identical to x86-32: 45 bytes vs. 46 bytes. NOTES 99 10 RV32/64 Privileged Architecture Edsger W. Dijkstra (1930–2002) received the 1972 Turing Award for fundamental contributions to developing programming languages. Simplicity is prerequisite for reliability. 10.1 Introduction —Edsger W. Dijkstra The book so far has focused on RISC-V support for general-purpose computation: all of the instructions we’ve introduced are available in user mode, where application code usually runs. This chapter introduces two new privilege modes: machine mode, which runs the most trusted code, and supervisor mode, which provides support for operating systems like Linux, FreeBSD, and Windows. Both new modes are more privileged than user mode, hence the title of the chapter. More-privileged modes generally have access to all of the features of less-privileged modes, and they add additional functionality not available to less-privileged modes, such as the ability to handle interrupts and perform I/O. Processors typically spend most of their execution time in their least-privileged mode; interrupts and exceptions transfer control to more-privileged modes. Embedded-system runtimes and operating systems use the features of these new modes to respond to external events, like the arrival of network packets; to support multitasking and protection between tasks; and to abstract and virtualize hardware features. Given the breadth of these topics, a thorough programmer’s guide would be an entire additional book; instead, this chapter aims to hit the high notes of the RISC-V features. Programmers disinterested in embedded system runtimes and operating systems can either skip or skim this chapter. Figure 10.1 is a graphical representation of the RISC-V privileged instructions, and Fig- ure 10.2 lists these instructions’ opcodes. As you can see, the privileged architecture adds RV32/64 Privileged Instructions machine-mode supervisor-mode trap return supervisor-mode fence.virtual memory address wait for interrupt Figure 10.1: Diagram of the RISC-V privileged instructions instructions. 10.2. MACHINEMODEFORSIMPLEEMBEDDEDSYSTEMS 101 31 27 26 25 24 20 19 15 14 12 11 7 6 0 0001000 00010 00000 000 00000 1110011 0011000 00010 00000 000 00000 1110011 0001000 00101 00000 000 00000 1110011 0001001 rs2 rs1 000 00000 1110011 R sret R mret R wfi R sfence.vma Figure 10.2: RISC-V privileged instruction layout, opcodes, format type, and name. (Table 6.1 of [Waterman and Asanovic ́ 2017] is the basis of this figure.) very few instructions; instead, several new control and status registers (CSRs) expose the additional functionality. This chapter describes the RV32 and RV64 privileged architectures together. Some con- cepts differ only in the size of an integer register, so to keep the descriptions concise, we introduce the term XLEN to refer to the width of an integer register in bits. XLEN is 32 for RV32 or 64 for RV64. 10.2 Machine Mode for Simple Embedded Systems Machine mode, abbreviated as M-mode, is the most privileged mode that a RISC-V hart (hardware thread) can execute in. Harts running in M-mode have full access to memory, I/O, and low-level system features necessary to boot and configure the system. As such, it is the only privilege mode that all standard RISC-V processors implement; indeed, simple RISC-V microcontrollers support only M-mode. Such systems are the focus of this section. The most important feature of machine mode is the ability to intercept and handle ex- ceptions: unusual runtime events. RISC-V classifies exceptions into two categories. Syn- chronous exceptions arise as a result of instruction execution, as when accessing an invalid memory address or executing an instruction with an invalid opcode. Interrupts are external events that are asynchronous with the instruction stream, like a mouse button click. Ex- ceptions in RISC-V are precise: all instructions prior to the exception completely execute, and none of the subsequent instructions appear to have begun execution. Figure 10.3 lists the standard exception causes. Five kinds of synchronous exceptions can happen during M-mode execution: • Access fault exceptions arise when a physical memory address doesn’t support the ac- cess type—for example, attempting to store to a ROM. • Breakpoint exceptions arise from executing an ebreak instruction, or when an address or datum matches a debug trigger. • Environment call exceptions arise from executing an ecall instruction. • Illegal instruction exceptions result from decoding an invalid opcode. • Misaligned address exceptions occur when the effective address isn’t divisible by the access size—for example, amoadd.w with an address of 0x12. If you recall Chapter 2’s claim that misaligned loads and stores are permitted, you might be wondering why misaligned load and store address exceptions are listed in Figure 10.3. There are two reasons. First, the atomic memory operations in Chapter 6 require natu- rally aligned addresses. Second, some implementors choose to omit hardware support for Hart is a contraction of hardware thread. We use the term to distin- guish them from software threads, which most pro- grammers are familiar with. Software threads are time- multiplexed on harts. Most processor cores have only one hart. Misaligned instruc- tion address excep- tions can’t occur with the C extension because it’s never possible to jump to an odd address: branches and JAL imme- diates are always even, and JALR masks off the least-significant bit of its effective address. With- out the C extension, this exception occurs when jumping to an address that is2mod4. 102 CHAPTER10. RV32/64PRIVILEGEDARCHITECTURE 􏰛 Interrupt Exception mcause[XLEN-1] Exception Code mcause[XLEN-2:0] Description 1 1 1 1 1 1 1 3 5 7 9 11 Supervisor software interrupt Machine software interrupt Supervisor timer interrupt Machine timer interrupt Supervisor external interrupt Machine external interrupt 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3 4 5 6 7 8 9 11 12 13 15 Instruction address misaligned Instruction access fault Illegal instruction Breakpoint Load address misaligned Load access fault Store address misaligned Store access fault Environment call from U-mode Environment call from S-mode Environment call from M-mode Instruction page fault Load page fault Store page fault Figure 10.3: RISC-V exception and interrupt causes. The most-significant bit of mcause is set to 1 for interrupts or 0 for synchronous exceptions, and the least-significant bits identify the interrupt or exception. Supervisor interrupts and page-fault exceptions are only possible when supervisor mode is implemented (see Section 10.5). (Table 3.6 of [Waterman and Asanovic ́ 2017] is the basis of this figure.) 10.3. MACHINE-MODEEXCEPTIONHANDLING 103 XLEN-1 XLEN-2 23 22 21 20 19 18 17 1 XLEN-24 111111 1615 1413 1211 109 8 7 6 5 4 3 2 1 0 2222111111111 Figure 10.4: The mstatus CSR. The only fields present in simple processors with only Machine mode and without the F and V extensions are the global interrupt enable, MIE, and MPIE, which after an exception holds the old value of MIE. XLEN is 32 for RV32, or 64 for RV64. Figure 3.7 of [Waterman and Asanovic ́ 2017] is the basis of this figure; see Section 3.1 of that document for a description of the other fields. misaligned regular loads and stores, because it is a difficult feature to implement and is in- frequently used. Processors without this hardware rely instead upon an exception handler to trap and emulate misaligned loads and stores in software, using a sequence of smaller, aligned loads and stores. Application code is none the wiser: misaligned memory accesses work as expected, albeit slowly, while the hardware remains simple. Alternatively, more performant processors can implement misaligned loads and stores in hardware. This imple- mentation flexibility owes to RISC-V’s decision to permit misaligned loads and stores using the regular load and store opcodes, following Chapter 1’s guideline to isolate architecture from implementation. There are three standard sources of interrupts: software, timer, and external. Software in- terrupts are triggered by storing to a memory-mapped register and are generally used by one hart to interrupt another hart, a mechanism other architectures refer to as an interprocessor interrupt. Timer interrupts are raised when a hart’s time comparator, a memory-mapped reg- ister named mtimecmp, exceeds the real-time counter mtime. External interrupts are raised by a platform-level interrupt controller, to which most external devices are attached. As different hardware platforms have different memory maps and demand divergent features of their interrupt controllers, the mechanisms for raising and clearing these interrupts differ from platform to platform. What is constant across all RISC-V systems is how exceptions are handled and interrupts are masked, the topic of the next section. 10.3 Machine-Mode Exception Handling Eight control and status registers (CSRs) are integral to machine-mode exception handling: • mtvec, Machine Trap Vector, holds the address the processor jumps to when an excep- tion occurs. • mepc, Machine Exception PC, points to the instruction where the exception occurred. • mcause, Machine Exception Cause, indicates which exception occurred. • mie,MachineInterruptEnable,listswhichinterruptstheprocessorcantakeandwhich it must ignore. • mip, Machine Interrupt Pending, lists the interrupts currently pending. SD 0 TSR TW TVM MXR SUM MPRV XS FS MPP 0 SPP MPIE 0 SPIE UPIE MIE 0 SIE UIE 104 CHAPTER10. RV32/64PRIVILEGEDARCHITECTURE Encoding Name Abbreviation 00 01 11 User Supervisor Machine U S M • • • Figure 10.5: RISC-V privilege levels and their encoding. mtval, Machine Trap Value, holds additional trap information: the faulting address for address exceptions, the instruction itself for illegal instruction exceptions, and zero for other exceptions. mscratch, Machine Scratch, holds one word of data for temporary storage. mstatus, Machine Status, holds the global interrupt enable, along with a plethora of other state, as Figure 10.4 shows. When executing in M-mode, interrupts are only taken if the global interrupt-enable bit, mstatus.MIE, is set. Furthermore, each interrupt has its own enable bit in the mie CSR. The bit positions in mie correspond to the interrupt codes in Figure 10.3: for example, mie[7] corresponds to the M-mode timer interrupt. The mip CSR has the same layout and indicates which interrupts are currently pending. Putting all three CSRs together, a machine timer interrupt can be taken if mstatus.MIE=1, mie[7]=1, and mip[7]=1. When a hart takes an exception, the hardware atomically undergoes several state transi- tions: • The PC of the exceptional instruction is preserved in mepc, and the PC is set to mtvec. (For synchronous exceptions, mepc points to the instruction that caused the exception; for interrupts, it points where execution should resume after the interrupt is handled.) • mcause is set to the exception cause, as encoded in Figure 10.3, and mtval is set to the faulting address or some other exception-specific word of information. • Interrupts are disabled by setting MIE=0 in the mstatus CSR, and the previous value of MIE is preserved in MPIE. • The pre-exception privilege mode is preserved in mstatus’ MPP field, and the privi- lege mode is changed to M. Figure 10.5 shows the encoding of the MPP field. (If the processor only implements M-mode, this step is effectively skipped.) To avoid overwriting the contents of the integer registers, the prologue of an interrupt handler usually begins by swapping an integer register (say, a0) with the mscratch CSR. Usually, the software will have arranged for mscratch to contain a pointer to additional in- memory scratch space, which the handler uses to save as many integer registers as its body will use. After the body executes, the epilogue of an interrupt handler restores the registers it saved to memory, then again swaps a0 with mscratch, restoring both registers to their pre-exception values. Finally, the handler returns with mret, an instruction unique to M- mode. mret sets the PC to mepc, restores the previous interrupt-enable setting by copying the mstatus MPIE field to MIE, and sets the privilege mode to the value in mstatus’ MPP field, essentially reversing the actions described in the preceding paragraph. RISC-V also sup- ports vectored in- terrupts, wherein the processor jumps to an interrupt-specific address, rather than a single entry point. This addressing eliminates the need to read and decode mcause, speeding up interrupt han- dling. Setting mtval[0] to 1 enables this feature; interrupt cause x then sets the PC to (mtval- 1+4x), instead of the usual mtval. 10.4. USERMODEANDPROCESSISOLATIONINEMBEDDEDSYSTEMS 105 Figure 10.6 shows RISC-V assembly code for a basic timer interrupt handler following this pattern. It simply increments the time comparator then returns to the previous task, whereas a more realistic timer interrupt handler might invoke a scheduler to switch between tasks. It is not preemptible, so it keeps interrupts disabled throughout the handler. Those caveats aside, it is a complete example of a RISC-V interrupt handler on a single page! Sometimes it’s desirable to take a higher-priority interrupt while processing a lower- priority exception. Alas, there’s only one copy of the mepc, mcause, mtval, and mstatus CSRs; taking a second interrupt would destroy the old values in these registers, causing data loss without some additional help from software. A preemptible interrupt handler can save these registers to an in-memory stack before enabling interrupts, then, just prior to exiting, disable interrupts and restore the registers from the stack. In addition to the mret instruction we introduced above, M-mode provides just one other instruction: wfi (Wait For Interrupt). wfi informs the processor that there isn’t any useful work to do, so it should enter a lower-power mode until any enabled interrupt becomes pend- ing, i.e., (mie & mip)̸=0. RISC-V processors implement this instruction in a variety of ways, including stopping the clock until an interrupt becomes pending; some simply execute it as a nop. Hence, wfi is typically used inside a loop. Elaboration: wfi works whether or not interrupts are globally enabled. If wfi is executed when interrupts are globally enabled (mstatus.MIE=1), and then an en- abled interrupt becomes pending, the processor jumps to the exception handler. If, on the other hand, wfi is executed when interrupts are globally disabled, and then an enabled inter- rupt becomes pending, the processor continues executing the code following the wfi. This code typically examines the mip CSR to decide what to do next. This strategy can reduce interrupt latency as compared to jumping to the exception handler, because there’s no need to save and restore integer registers. 10.4 User Mode and Process Isolation in Embedded Systems Although Machine mode is sufficient for simple embedded systems, it is only suitable when the entire codebase is trusted, since M-mode has unfettered access to the hardware platform. More often, it is not practical to trust all of the application code, because it is not known in advance or is too vast to prove correct. So, RISC-V provides mechanisms to protect the system from the untrusted code, and to protect untrusted processes from each other. Untrusted code must be forbidden from executing privileged instructions, like mret, and accessing privileged CSRs, like mstatus, as these would allow the program to take control of the system. This restriction is accomplished easily enough: an additional privilege mode, User mode (U-mode), denies access to these features, generating an illegal instruction excep- tion when attempting to use an M-mode instruction or CSR. Otherwise, U-mode and M-mode behave very similarly. M-mode software can enter U-mode by setting mstatus.MPP to U (which, as Figure 10.5 shows, is encoded as 0), then executing an mret instruction. If an exception occurs in U-mode, control is returned to M-mode. Untrusted code must also be restricted to access only its own memory. Processors that implement M and U modes have a feature called Physical Memory Protection (PMP), which allows M-mode to specify which memory addresses U-mode can access. PMP consists of several address registers (usually eight to sixteen) and corresponding configuration registers, which grant or deny read, write, and execute permissions. When a processor in U-mode 106 CHAPTER10. RV32/64PRIVILEGEDARCHITECTURE # save registers csrrw a0, mscratch, a0 # save a0; set a0 = &temp storage sw a1, 0(a0) sw a2, 4(a0) sw a3, 8(a0) sw a4, 12(a0) # decode interrupt cause # save a1 # save a2 # save a3 # save a4 csrr a1, mcause bgez a1, exception andi a1, a1, 0x3f lia2,7 bne a1, a2, otherInt # read exception cause # branch if not an interrupt # isolate interrupt cause # a2 = timer interrupt cause # branch if not a timer interrupt # handle timer interrupt by incrementing time comparator la a1, mtimecmp lw a2, 0(a1) lw a3, 4(a1) addi a4, a2, 1000 sltu a2, a4, a2 add a3, a3, a2 sw a3, 4(a1) sw a4, 0(a1) # a1 = &time comparator # load lower 32 bits of comparator # load upper 32 bits of comparator # increment lower bits by 1000 cycles # generate carry-out # increment upper bits # store upper 32 bits # store lower 32 bits # restore registers and return lw a4, 12(a0) lw a3, 4(a0) lw a2, 4(a0) lw a1, 0(a0) csrrw a0, mscratch, a0 # restore a0; mscratch = &temp storage mret # return from handler Figure 10.6: RISC-V code for a simple timer interrupt handler. The code assumes that interrupts are globally enabled by setting mstatus.MIE; that timer interrupts have been enabled by setting mie[7]; that the mtvec CSR has been set to the address of this handler; and that the mscratch CSR has been set to the address of a buffer that contains 16 bytes of temporary storage to save the registers. The prologue saves five registers, preserving a0 in mscratch and a1–a4 in memory. It then decodes the exception cause by examining mcause: interrupt if mcause<0, or synchronous exception if mcause≥0. If it is an interrupt, it checks that the lower bits of mcause equal 7, indicating an M-mode timer interrupt. If it is a timer interrupt, it adds 1000 cycles to the time comparator, so that the next timer interrupt will occur about 1000 timer cycles in the future. Finally, the epilogue restores the a0–a4 and mscratch, then returns whence it came using mret. # restore a4 # restore a3 # restore a2 # restore a1 10.4. USERMODEANDPROCESSISOLATIONINEMBEDDEDSYSTEMS 107 XLEN-1 0 address[PhysicalAddressSize-1:2] 76543210 L 0 A X W R Figure 10.7: A PMP address and configuration register. The address register is right-shifted by 2, and if physical addresses are less than XLEN-2 bits wide, the upper bits are zeros. The R, W, and X fields grant read, write, and execute permissions. The A field sets the PMP mode, and the L field locks the PMP and corresponding address registers. 31 24 23 16 15 RV32 32 31 RV64 8 7 0 PMP3 PMP2 PMP1 PMP0 pmpcfg0 pmpcfg1 pmpcfg2 pmpcfg3 PMP7 PMP6 PMP5 PMP4 PMP11 PMP10 PMP9 PMP8 PMP15 PMP14 PMP13 PMP12 63 56 55 48 47 40 39 24 23 16 15 8 7 0 PMP7 PMP6 PMP5 PMP4 PMP3 PMP2 PMP1 PMP0 pmpcfg0 pmpcfg2 PMP15 PMP14 PMP13 PMP12 PMP11 PMP10 PMP9 PMP8 Figure 10.8: The layout of PMP configurations in the pmpcfg CSRs. For RV32 (above), the sixteen configuration registers are packed into four CSRs. For RV64 (below), they are packed into the two even-numbered CSRs. attempts to fetch an instruction, or execute a load or store, the address is compared against all of the PMP address registers. If the address is greater than or equal to PMP address i, but less than PMP address i+1, then PMP i+1’s configuration register decides whether that access may proceed; otherwise, it raises an access exception. Figure 10.7 shows the layout of a PMP address and configuration register. Both are CSRs, with the address registers named pmpaddr0 to pmpaddrN, where N+1 is the number of PMPs implemented. The address registers are shifted right two bits because PMPs have a four-byte granularity. The configuration registers are densely packed in the CSRs to accelerate context switching, as Figure 10.8 shows. A PMP’s configuration consists of R, W, and X bits, which when set permit loads, stores, and fetches, respectively, and a mode field, A, which when 0 disables this PMP or when 1 enables it. The PMP configuration also supports other modes and can be locked, features described in [Waterman and Asanovic ́ 2017]. 108 CHAPTER10. RV32/64PRIVILEGEDARCHITECTURE 10.5 Supervisor Mode for Modern Operating Systems The PMP scheme described in the previous section is attractive for embedded systems be- cause it provides memory protection at relatively low cost, but it has several drawbacks that limit its use in general-purpose computing. Since PMP supports only a fixed number of memory regions, it doesn’t scale to complex applications. And since these regions must be contiguous in physical memory, the system can suffer from memory fragmentation. Finally, PMP doesn’t efficiently support paging to secondary storage. More sophisticated RISC-V processors handle these problems the same way as nearly all general-purpose architectures: using page-based virtual memory. This feature forms the core of supervisor mode (S-mode), an optional privilege mode designed to support modern Unix- like operating systems, such as Linux, FreeBSD, and Windows. S-mode is more privileged than U-mode, but less-privileged than M-mode. Like U-mode, S-mode software can’t use M- mode CSRs and instructions, and is subject to PMP restrictions. This section covers S-mode interrupts and exceptions, and the next section details the S-mode virtual-memory system. By default, all exceptions, regardless of privilege mode, transfer control to the M-mode exception handler. Most exceptions in a Unix system, though, should invoke the operating system, which runs in S-mode. The M-mode exception handler could re-route exceptions to S-mode, but this extra code would slow down the handling of most exceptions. So, RISC-V provides an exception delegation mechanism, by which interrupts and synchronous excep- tions can be delegated to S-mode selectively, bypassing M-mode software altogether. The mideleg (Machine Interrupt Delegation) CSR controls which interrupts are dele- gated to S-mode. Like mip and mie, each bit in mideleg corresponds to the exception code of the same number in Figure 10.3. For example, mideleg[5] corresponds to the S-mode timer interrupt; if set, S-mode timer interrupts will transfer control to the S-mode exception handler, rather than the M-mode exception handler. Any interrupt delegated to S-mode can be masked by S-mode software. The sie (Super- visor Interrupt Enable) and sip (Supervisor Interrupt Pending) CSRs are S-mode CSRs that are subsets of the mie and mip CSRs. They have the same layout as their M-mode counter- parts, but only the bits corresponding to interrupts that have been delegated in mideleg are readable and writable through sie and sip. The bits corresponding to interrupts that haven’t been delegated are always zero. M-mode can also delegate synchronous exceptions to S-mode using the medeleg (Ma- chine Exception Delegation) CSR. The mechanism is analogous to interrupt delegation, but the bits in medeleg correspond instead to the synchronous exception codes in Figure 10.3. For example, setting medeleg[15] will delegate store page faults to S-mode. Note that exceptions will never transfer control to a less-privileged mode, no matter the delegation settings. An exception that occurs in M-mode is always handled in M-mode. An exception that occurs in S-mode might be handled by either M-mode or S-mode, depending on the delegation configuration, but never U-mode. S-mode has several exception-handling CSRs, sepc, stvec, scause, sscratch, stval, and sstatus, which perform the same function as their M-mode counterparts described in Section 10.2. Figure 10.9 shows the layout of the sstatus register. The supervisor exception return instruction, sret, behaves the same as mret, but it acts on the S-mode exception- handling CSRs instead of the M-mode ones. The act of taking an exception is also very similar to M-mode. If a hart takes an excep- tion and it is delegated to S-mode, the hardware atomically undergoes several similar state Fragmentation occurs when memory is available, but not in large enough contiguous chunks to be useful. Why not uncondi- tionally delegate in- terrupts to S-mode? One reason is virtualiza- tion: if M-mode wants to virtualize a device for S-mode, its interrupts should go to M-mode, not S-mode. S-mode doesn’t di- rectly control timer and software inter- rupts but instead uses the ecall instruction to request M-mode to set up timers or send interproces- sor interrupts on its behalf. This software convention is part of the Supervisor Binary Interface. 10.6. PAGE-BASEDVIRTUALMEMORY 109 XLEN-1 XLEN-2 1 20 19 18 17 1 1 1 SD 0 MXR SUM 0 XLEN-21 16 15 14 13 129 8 76 5 4 32 1 0 XS[1:0] 2241211211 Figure 10.9: The sstatus CSR. sstatus is a subset of mstatus (Figure 10.4), hence the similar layout. SIE and SPIE hold the current and pre-exception interrupt enables, analogous to MIE and MPIE in mstatus. XLEN is 32 for RV32, or 64 for RV64. Figure 4.2 of [Waterman and Asanovic ́ 2017] is the basis of this figure; see Section 4.1 of that document for a description of the other fields. transitions, using S-mode CSRs instead of M-mode ones: • The PC of the exceptional instruction is preserved in sepc, and the PC is set to stvec. • scause is set to the exception cause, as encoded in Figure 10.3, and stval is set to the faulting address or some other exception-specific word of information. • Interrupts are disabled by setting SIE=0 in the sstatus CSR, and the previous value of SIE is preserved in SPIE. • Thepre-exceptionprivilegemodeispreservedinsstatus’SPPfield,andtheprivilege mode is changed to S. 10.6 Page-Based Virtual Memory S-mode provides a conventional virtual memory system that divides memory into fixed-size pages for the purposes of address translation and memory protection. When paging is en- abled, most addresses (including load and store effective addresses and the PC) are virtual addresses that must be translated into physical addresses in order to access physical memory. Virtual addresses are translated to physical addresses by traversing a high-radix tree known as the page table. A leaf node in the page table indicates whether the virtual address maps to a physical page, and, if so, which privilege modes and access types have permission to access the page. Accessing a page that is unmapped or grants insufficient permissions results in a page fault exception. RISC-V paging schemes are named SvX, where X is the size of a virtual address in bits. RV32’s paging scheme, Sv32, supports a 4 GiB virtual-address space, which is divided into 210 megapages of size 4 MiB. Each megapage is subdivided into 210 base pages—the funda- mental unit of paging—each 4 KiB. Hence, Sv32’s page table is a two-level tree of radix 210 . Each entry in the page table is four bytes, so a page table is itself 4 KiB. It’s no coincidence that a page table is exactly the size of a page: this design simplifies operating-system memory allocation. Figure 10.10 shows the layout of an Sv32 page-table entry (PTE), which has the following fields, explained from right to left: • The V bit indicates whether the rest of this PTE is valid (V=1). If V=0, any virtual- address translation that traverses this PTE results in a page fault. FS[1:0] 0 SPP 0 SPIE UPIE 0 SIE UIE 4 KiB pages have been popular for five decades starting with the IBM 360 model 67. Atlas, the first com- puter with paging, had 3 KiB pages (it had 6- byte words). We find it remarkable that, after a half-century of exponen- tial growth in computer performance and memory capacity, the page size re- mains virtually unchanged. 110 CHAPTER10. RV32/64PRIVILEGEDARCHITECTURE 31 5453 10 26 9 9 211111111 Figure 10.11: An RV64 Sv39 page-table entry (PTE). The R, W, and X bits indicate whether the page has read, write, and execute permis- sions, respectively. If all three bits are 0, this PTE is a pointer to the next level of the page table; otherwise, it’s a leaf of the tree. The U bit indicates whether this page is a user page. If U=0, U-mode cannot access this page, but S-mode can. If U=1, U-mode can access this page, but S-mode cannot. The G bit indicates this mapping exists in all virtual-address spaces, information the hardware can use to improve address-translation performance. It is typically only used for pages that belong to the operating system. The A bit indicates whether the page has been accessed since the last time the A bit was cleared. The D bit indicates whether the page has been dirtied (i.e., written) since the last time the D bit was cleared. The RSW field is reserved for the operating system’s use; the hardware ignores it. The PPN field holds a physical page number, which is part of a physical address. If this PTE is a leaf, the PPN is part of the translated physical address. Otherwise, the PPN gives the address of the next level of the page table. (Figure 10.10 divides the PPN into two subfields to simplify the description of the address-translation algorithm.) PPN[1] PPN[0] RSW D A G U X W R V 63 • • • • • • • 2827 1918 109 876543210 12 2019 109 876543210 10 2 11111111 Figure 10.10: An RV32 Sv32 page-table entry (PTE). Reserved PPN[2] PPN[1] PPN[0] RSW D A G U X W R V The OS relies on the A and D bits to de- cide which pages to swap to secondary storage. Periodically clearing the A bits helps the OS approximate which pages have been least- recently used. The D bit indicates a page is even more expensive to swap out, because it must be written back to secondary storage. The other RV64 pag- ing schemes simply add more levels to the page table. Sv48 is nearly identical to Sv39, but its virtual-address space is 29 times bigger and its page table is one level deeper. RV64 supports multiple paging schemes, but we describe only the most popular one, Sv39. Sv39 uses the same 4 KiB base page as Sv32. The page-table entries double in size to eight bytes so they can hold bigger physical addresses. To maintain the invariant that a page table is exactly the size of a page, the radix of the tree correspondingly falls to 29. The tree is three levels deep. Sv39’s 512 GiB address space is divided into 29 gigapages, each 1 GiB. Each gigapage is subdivided into 29 megapages, which in Sv39 are slightly smaller than in Sv32: 2 MiB. Each megapage is subdivided into 29 4 KiB base pages. Figure 10.11 shows the layout of an Sv39 PTE. It’s identical to an Sv32 PTE, except the PPN field has been widened to 44 bits to support 56-bit physical addresses, or 226 GiB of physical-address space. 10.6. PAGE-BASEDVIRTUALMEMORY 111 3130 2221 1 9 22 63 6059 4443 416 44 0 MODE ASID PPN RV32 0 MODE ASID PPN RV64 Figure 10.12: The satp CSR. Figures 4.11 and 4.12 of [Waterman and Asanovic ́ 2017] are the bases for this figure. RV32 Value Name Description 0 1 Bare Sv32 No translation or protection. Page-based 32-bit virtual addressing. RV64 Value Name Description 0 8 9 Bare Sv39 Sv48 No translation or protection. Page-based 39-bit virtual addressing. Page-based 48-bit virtual addressing. Figure 10.13: The encoding of the MODE field in the satp CSR. Table 4.3 of [Waterman and Asanovic ́ 2017] is the basis for this figure. Elaboration: Unused address bits Since Sv39’s virtual addresses are narrower than an RV64 integer register, you might wonder what becomes of the remaining 25 bits. Sv39 mandates that address bits 63–39 be copies of bit 38. Thus, the valid virtual addresses are 0000_0000_0000_0000hex– 0000_003f_ffff_ffffhex and ffff_ffc0_0000_0000hex–ffff_ffff_ffff_ffffhex. The gap between these two ranges is, of course, 225 times bigger than the size of the two ranges combined, seemingly wasting 99.999997% of the values a 64-bit register can repre- sent. Why not make better use of those extra 25 bits? The answer is that, as programs grow to require more than 512 GiB of virtual-address space, architects want to increase the ad- dress space without breaking backwards compatibility. If we allowed programs to store extra data in the upper 25 bits, it would be impossible to later reclaim those bits to hold bigger addresses. Allowing data storage in unused address bits is a grievous error, but one that has recurred many times in computing history. An S-mode CSR, satp (Supervisor Address Translation and Protection), controls the paging system. As Figure 10.12 shows, satp has three fields. The MODE field enables paging and selects the page-table depth; Figure 10.13 shows its encoding. The ASID (Address Space Identifier) field is optional and can be used to reduce the cost of context switches. Finally, the PPN field holds the physical address of the root page table, divided by the 4 KiB page size. Typically, M-mode software will write zero to satp before entering S-mode for the first time, disabling paging, then S-mode software will write it again after setting up the page tables. 112 CHAPTER10. RV32/64PRIVILEGEDARCHITECTURE VA 31 22 21 Page Table 12 11 Page Table 12 11 0 VPN[1] VPN VPN[0] offset satp PTE PTE 33 0 PA PPN offset Figure 10.14: Diagram of the Sv32 address-translation process. When paging is enabled in the satp register, S-mode and U-mode virtual addresses are translated into physical addresses by traversing the page table, starting at the root. Fig- ure 10.14 depicts this process: 1. satp.PPN gives the base address of the first-level page table, and VA[31:22] gives the first-level index, so the processor reads the PTE located at address (satp.PPN×4096 + VA[31:22]×4). 2. ThatPTEcontainsthebaseaddressofthesecond-levelpagetableandVA[21:12]gives the second-level index, so the processor reads the leaf PTE located at (PTE.PPN×4096 + VA[21:12]×4). 3. The leaf PTE’s PPN field and the page offset (the twelve least-significant bits of the original virtual address) form the final result: the physical address is (LeafPTE.PPN×4096 + VA[11:0]). The processor then performs the physical memory access. The translation process is almost the same for Sv39 as for Sv32, but with larger PTEs and one more level of indirec- tion. Figure 10.19, at the end of this chapter, gives a complete description of the page-table traversal algorithm, detailing the exceptional conditions and the special case of superpage translations. That’s almost all there is to the RISC-V paging system, save for one wrinkle. If all instruction fetches, loads, and stores resulted in several page-table accesses, then paging would reduce performance substantially! All modern processors reduce this overhead with an address-translation cache (often called a TLB, for Translation Lookaside Buffer). To reduce the cost of this cache, most processors don’t automatically keep it coherent with the page table—if the operating system modifies the page table, the cache becomes stale. S- mode adds one more instruction to solve this problem: sfence.vma informs the processor 10.7. CONCLUDINGREMARKS 113 XLEN-1 12 11 10 9 8 7 6 5 4 3 2 1 0 XLEN-12 1 1 1 1 1 1 1 1 1 1 1 1 Figure 10.15: Machine interrupt registers. They are XLEN-bit read/write registers that hold pending interrupts (mip) and the interrupt enable bits (mie) CSRs. Only the bits corresponding to lower-privilege software interrupts (USIP, SSIP), timer interrupts (UTIP, STIP), and external interrupts (UEIP, SEIP) in mip are writable through this CSR address; the remaining bits are read-only. XLEN-1 10 9 8 7 6 5 4 3 2 1 0 XLEN-10 1 1 2 1 1 2 1 1 Figure 10.16: Supervisor interrupt registers. They are XLEN-bit read/write registers that hold pending interrupts (sip) and the interrupt enable bits (sie) CSRs. that software may have modified the page tables, so the processor can flush the translation caches accordingly. It takes two optional arguments, which narrow the scope of the cache flush: rs1 indicates which virtual address’ translation has been modified in the page table, and rs2 gives the address-space identifier of the process whose page table has been modified. If x0 is given for both, the entire translation cache is flushed. WIRI MEIP WIRI SEIP UEIP MTIP WIRI STIP UTIP MSIP WIRI SSIP USIP WPRI MEIE WPRI SEIE UEIE MTIE WPRI STIE UTIE MSIE WPRI SSIE USIE WIRI SEIP UEIP WIRI STIP UTIP WIRI SSIP USIP WPRI SEIE UEIE WPRI STIE UTIE WPRI SSIE USIE 10.7 Elaboration: Address-translation cache coherence in multiprocessors sfence.vma only affects the address-translation hardware for the hart that executed the in- struction. When a hart changes a page table that another hart is using, the first hart must use an interprocessor interrupt to inform the second hart that it should execute an sfence.vma instruction. This procedure is often referred to as a TLB shootdown. Concluding Remarks Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude. —Fred Brooks, Jr., 1986. Brooks is a Turing Award laureate and an architect of the IBM System/360 family of computers, which demonstrated the importance of differentiating architecture from im- plementation. Descendants of that 1964 architecture are still selling today. The modularity of the RISC-V privileged architectures caters to the needs of a variety of systems. The minimalist Machine mode supports bare-metal embedded applications at low cost. The additional User mode and Physical Memory Protection together enable multitask- ing in more sophisticated embedded systems. Finally, Supervisor mode and page-based virtual memory provide the flexibility needed to host modern operating systems. 114 NOTES XLEN-1 21 0 2 BASE[XLEN-1:2] MODE XLEN-2 Figure 10.17: Machine and supervisor trap-vector base-address register (mtvec and stvec) CSRs. They are XLEN-bit read/write registers that hold trap vector configuration, consisting of a vector base address (BASE) and a vector mode (MODE). The value in the BASE field must always be aligned on a 4-byte boundary. MODE = 0 means all exceptions set the PC to BASE. MODE = 1 sets the PC to (BASE + (4 × cause)) on asynchronous interrupts. XLEN-1 XLEN-2 0 1 XLEN-1 Figure10.18: Machineandsupervisorcause(mcauseandscause)CSRs.Whenatrapistaken,theCSRis written with a code indicating the event that caused the trap. The Interrupt bit is set if the trap was caused by an interrupt. The Exception Code field contains a code identifying the last exception. Tables 3.6 and 4.2 of [Waterman and Asanovic ́ 2017] map the code values to the reason for the traps. Interrupt Exception Code 10.8 To Learn More A. Waterman and K. Asanovic ́, editors. II: Privileged Architecture Version 1.10. specifications/privileged-isa/. Notes 1 http://parlab.eecs.berkeley.edu The RISC-V Instruction Set Manual Volume May 2017. URL https://riscv.org/ NOTES 115 1. Letabesatp.ppn×PAGESIZE,andleti=LEVELS−1. 2. LetptebethevalueofthePTEataddressa+va.vpn[i]×PTESIZE. 3. If pte.v = 0, or if pte.r = 0 and pte.w = 1, stop and raise a page-fault exception. 4. Otherwise, the PTE is valid. If pte.r = 1 or pte.x = 1, go to step 5. Otherwise, this PTE is a pointer to the next level of the page table. Let i = i − 1. If i < 0, stop and raise a page-fault exception. Otherwise, let a = pte.ppn × PAGESIZE and go to step 2. 5. A leaf PTE has been found. Determine if the requested memory access is allowed by the pte.r, pte.w, pte.x, and pte.u bits, given the current privilege mode and the value of the SUM and MXR fields of the mstatus register. If not, stop and raise a page-fault exception. 6. If i > 0 and pa.ppn[i − 1 : 0] ̸= 0, this is a misaligned superpage; stop and raise a page-fault exception.
7. If pte.a = 0, or if the memory access is a store and pte.d = 0, then either: • Raiseapage-faultexception,or:
• Setpte.ato1and,ifthememoryaccessisastore,alsosetpte.dto1.
8. The translation is successful. The translated physical address is given as follows: • pa.pgoff = va.pgoff.
• If i > 0, then this is a superpage translation and pa.ppn[i − 1 : 0] = va.vpn[i − 1 : 0]. • pa.ppn[LEVELS − 1 : i] = pte.ppn[LEVELS − 1 : i].
Figure 10.19: The complete algorithm for virtual-to-physical address translation. va is the virtual address input and pa is the physical address output. The PAGESIZE constant is 212. For Sv32, LEVELS=2 and PTESIZE=4, whereas for Sv39, LEVELS=3 and PTESIZE=8. Section 4.3.2 of [Waterman and Asanovic ́ 2017] is the basis for this figure.

11
Future RISC-V Optional Extensions
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
—Alan Perlis, 1982 The RISC-V Foundation will develop at least eight optional extensions.
11.1 “B” Standard Extension for Bit Manipulation
The B extension offers bit manipulation, including insert, extract, and test bit fields; rotations; funnel shifts; bit and byte permutations; count leading and trailing zeros; and count bits set.
11.2 “E” Standard Extension for Embedded
To reduce the cost of low-end cores, it has 16 fewer registers. RV32E is why the saved and temporary registers are split between the registers 0-15 and 16-31 (Figure 3.2).
11.3 “H” Privileged Architecture Extension for Hypervisor Support
The H extension to the privileged architecture adds a new hypervisor mode and a second level of page-based address translation to improve the efficiency of running multiple operating systems on the same machine.
11.4 “J” Standard Extension for Dynamically Translated Languages
Many popular languages are usually implemented via dynamic translation, including Java and Javascript. These languages can benefit from additional ISA support for dynamic checks and garbage collection. (J stands for Just-In-Time compiler.)
11.5 “L” Standard Extension for Decimal Floating-Point
The L extension is intended to support decimal floating-point arithmetic as defined in the IEEE 754-2008 standard. The problem with binary numbers is that they cannot represent some common decimal fractions, such as 0.1. The motivation for RV32L is that the compu- tation radix can be identical to the radix of the input and output.
Alan Perlis (1922–1990) was the first recipient of
the Turing Award (1966), conferred for his influence on advanced programming languages and compilers. In 1958 he helped design AL- GOL, which has influenced virtually every imperative programming language including C and Java.

11.6. “N”STANDARDEXTENSIONFORUSER-LEVELINTERRUPTS 117 11.6 “N” Standard Extension for User-Level Interrupts
The N extension allows interrupts and exceptions that occur in user-level programs to transfer control directly to a user-level trap handler without invoking the outer execution environment. User-level interrupts are mainly intended to support secure embedded systems with only M- mode and U-mode present (Chapter 10). However, they can also support user-level trap handlinginsystemsrunningUnix-likeoperatingsystems. WhenusedinaUnixenvironment, conventional signal handling would likely remain, but user-level interrupts could be used as a building block for future extensions that generate user-level events such as garbage collection barriers, integer overflow, and floating-point traps.
11.7 “P” Standard Extension for Packed-SIMD Instructions
The P extension subdivides the existing architectural registers to provide data-parallel compu- tation on smaller data types. Packed-SIMD designs represent a reasonable design point when reusing existing wide datapath resources. However, if significant additional resources are to be devoted to data-parallel execution, Chapter 8 shows that designs for vector architectures are a better choice, and architects should use the RVV extension.
11.8 “Q” Standard Extension for Quad-Precision Floating-Point
The Q extension adds 128-bit quad-precision binary floating-point instructions compliant with the IEEE 754-2008 arithmetic standard. The floating-point registers are now extended to hold either a single, double, or quad-precision floating-point value. The quad-precision binary floating-point extension requires RV64IFD.
11.9 Concluding Remarks
Simplify, simplify.
—Henry David Thoreau, an eminent writer of the 19th century, 1854
Having an open, standards-like committee approach to expanding RISC-V hopefully will mean that the feedback and debate will occur before the instructions are finalized rather than afterwards, when it’s too late to change. In the ideal case, a few members will implement the proposal before it is ratified, which FPGAs make much easier to do. Proposing instruction extensions via the RISC-V Foundation committees will also be a fair amount of work, which will keep the rate of change slow, unlike what happened to x86-32 (see Figure 1.2 on page 3 in Chapter 1). Don’t forget that everything in this chapter will be optional, despite how many extensions are adopted.
Our hope is that RISC-V can evolve with technological demands while maintaining its reputation as a simple, efficient ISA. If it succeeds, RISC-V will we be a significant break from the incremental ISAs of the past.

A
RISC-V Instruction Listings
Simplicity is the keynote of all true elegance.
—Coco Chanel, 1923
This appendix lists all the instructions for RV32/64I, all the extensions covered in this book (RVM, RVA, RVF, RVD, RVC, and RVV), and all the pseudoinstructions. Each entry has the instruction name, operands, a register-transfer level definition, instruction format type, English description, compressed versions (if any), and a figure showing the actual layout with opcodes. We think you have everything you need to understand all the instructions in these compact summaries. However, if you want even more detail, refer to the official RISC-V specifications [Waterman and Asanovic ́ 2017].
To help readers find the desired instruction in this appendix, the header of the left (even) page contains the first instruction from the top of that page and the header on the right (odd) page contains the last instruction from at the bottom of that page. The format is similar to the headers of dictionaries, which helps you search for the page that your word is on. For example, the header of the next even page shows AMOADD.W, the first instruction on the page, and the header of the following odd page shows AMOMINU.D, the last instruction on that page. These are the two pages where you would find any of these 10 instructions: amoadd.w, amoand.d, amoand.w, amomax.d, amomax.w, amomaxu.d, amomaxu.w, amomin.d, amomin.w, and amominu.d.
Coco Chanel (1883- 1971) Founder of the Chanel fashion brand, her pursuit of expensive sim- plicity shaped 20th-century fashion.

RISC-V INSTRUCTIONS: AMOADD.D 119
add rd, rs1, rs2 x[rd] = x[rs1] + x[rs2] Add. R-type, RV32I and RV64I.
Adds register x[rs2] to register x[rs1] and writes the result to x[rd]. Arithmetic overflow is ignored.
Compressed forms: c.add rd, rs2; c.mv rd, rs2
31 25 24 20 19 15 14 12 11 7 6 0
addi rd, rs1, immediate x[rd] = x[rs1] + sext(immediate) Add Immediate. I-type, RV32I and RV64I.
Adds the sign-extended immediate to register x[rs1] and writes the result to x[rd]. Arithmetic overflow is ignored.
Compressed forms: c.li rd, imm; c.addi rd, imm; c.addi16sp imm; c.addi4spn rd, imm 31 20 19 15 14 12 11 7 6 0
addiw rd, rs1, immediate x[rd] = sext((x[rs1] + sext(immediate))[31:0]) Add Word Immediate. I-type, RV64I only.
Adds the sign-extended immediate to x[rs1], truncates the result to 32 bits, and writes the sign-extended result to x[rd]. Arithmetic overflow is ignored.
Compressed form: c.addiw rd, imm
31 20 19 15 14 12 11 7 6 0
addw rd, rs1, rs2 x[rd] = sext((x[rs1] + x[rs2])[31:0]) Add Word. R-type, RV64I only.
Adds register x[rs2] to register x[rs1], truncates the result to 32 bits, and writes the sign- extended result to x[rd]. Arithmetic overflow is ignored.
Compressed form: c.addw rd, rs2
31 25 24 20 19 15 14 12 11 7 6 0
amoadd.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] + x[rs2]) Atomic Memory Operation: Add Doubleword. R-type, RV64A only.
Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to t + x[rs2]. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
0000000
rs2
rs1
000
rd
0110011
immediate[11:0]
rs1
000
rd
0010011
immediate[11:0]
rs1
000
rd
0011011
0000000
rs2
rs1
000
rd
0111011
00000
aq
rl
rs2
rs1
011
rd
0101111

120 RISC-V INSTRUCTIONS: AMOADD.W
amoadd.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] + x[rs2]) Atomic Memory Operation: Add Word. R-type, RV32A and RV64A.
Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to t + x[rs2]. Set x[rd] to the sign extension of t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amoand.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] & x[rs2]) Atomic Memory Operation: AND Doubleword. R-type, RV64A only.
Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to the bitwise AND of t and x[rs2]. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amoand.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] & x[rs2]) Atomic Memory Operation: AND Word. R-type, RV32A and RV64A.
Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to the bitwise AND of t and x[rs2]. Set x[rd] to the sign extension of t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amomax.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] MAX x[rs2]) Atomic Memory Operation: Maximum Doubleword. R-type, RV64A only.
Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to the larger of t and x[rs2], using a two’s complement comparison. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amomax.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] MAX x[rs2]) Atomic Memory Operation: Maximum Word. R-type, RV32A and RV64A.
Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to the larger of t and x[rs2], using a two’s complement comparison. Set x[rd] to the sign extension of t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
00000
aq
rl
rs2
rs1
010
rd
0101111
01100
aq
rl
rs2
rs1
011
rd
0101111
01100
aq
rl
rs2
rs1
010
rd
0101111
10100
aq
rl
rs2
rs1
011
rd
0101111
10100
aq
rl
rs2
rs1
010
rd
0101111

RISC-V INSTRUCTIONS: AMOMINU.D 121
amomaxu.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] MAXU x[rs2]) Atomic Memory Operation: Maximum Doubleword, Unsigned. R-type, RV64A only. Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to the larger of t and x[rs2], using an unsigned comparison. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amomaxu.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] MAXU x[rs2]) Atomic Memory Operation: Maximum Word, Unsigned. R-type, RV32A and RV64A. Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to the larger of t and x[rs2], using an unsigned comparison. Set x[rd] to the sign extension of t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amomin.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] MIN x[rs2]) Atomic Memory Operation: Minimum Doubleword. R-type, RV64A only.
Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to the smaller of t and x[rs2], using a two’s complement comparison. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amomin.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] MIN x[rs2]) Atomic Memory Operation: Minimum Word. R-type, RV32A and RV64A.
Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to the smaller of t and x[rs2], using a two’s complement comparison. Set x[rd] to the sign extension of t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amominu.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] MINU x[rs2]) Atomic Memory Operation: Minimum Doubleword, Unsigned. R-type, RV64A only. Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to the smaller of t and x[rs2], using an unsigned comparison. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
11100
aq
rl
rs2
rs1
011
rd
0101111
11100
aq
rl
rs2
rs1
010
rd
0101111
10000
aq
rl
rs2
rs1
011
rd
0101111
10000
aq
rl
rs2
rs1
010
rd
0101111
11000
aq
rl
rs2
rs1
011
rd
0101111

122 RISC-V INSTRUCTIONS: AMOMINU.W
amominu.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] MINU x[rs2]) Atomic Memory Operation: Minimum Word, Unsigned. R-type, RV32A and RV64A. Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to the smaller of t and x[rs2], using an unsigned comparison. Set x[rd] to the sign extension of t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amoor.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] | x[rs2]) Atomic Memory Operation: OR Doubleword. R-type, RV64A only.
Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to the bitwise OR of t and x[rs2]. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amoor.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] | x[rs2]) Atomic Memory Operation: OR Word. R-type, RV32A and RV64A.
Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to the bitwise OR of t and x[rs2]. Set x[rd] to the sign extension of t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amoswap.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] SWAP x[rs2]) Atomic Memory Operation: Swap Doubleword. R-type, RV64A only.
Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to x[rs2]. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amoswap.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] SWAP x[rs2]) Atomic Memory Operation: Swap Word. R-type, RV32A and RV64A.
Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to x[rs2]. Set x[rd] to the sign extension of t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
11000
aq
rl
rs2
rs1
010
rd
0101111
01000
aq
rl
rs2
rs1
011
rd
0101111
01000
aq
rl
rs2
rs1
010
rd
0101111
00001
aq
rl
rs2
rs1
011
rd
0101111
00001
aq
rl
rs2
rs1
010
rd
0101111

RISC-V INSTRUCTIONS: AUIPC 123
amoxor.d rd, rs2, (rs1) x[rd] = AMO64(M[x[rs1]] ˆ x[rs2]) Atomic Memory Operation: XOR Doubleword. R-type, RV64A only.
Atomically, let t be the value of the memory doubleword at address x[rs1], then set that memory doubleword to the bitwise XOR of t and x[rs2]. Set x[rd] to t.
31 27 26 25 24 20 19 15 14 12 11 7 6 0
amoxor.w rd, rs2, (rs1) x[rd] = AMO32(M[x[rs1]] ˆ x[rs2]) Atomic Memory Operation: XOR Word. R-type, RV32A and RV64A.
Atomically, let t be the value of the memory word at address x[rs1], then set that memory word to the bitwise XOR of t and x[rs2]. Set x[rd] to the sign extension of t.
00100
aq
rl
rs2
rs1
011
rd
0101111
31 27 26 25 24 20 19 15 14 12 11
and rd, rs1, rs2
AND. R-type, RV32I and RV64I.
Computes the bitwise AND of registers x[rs1] and x[rs2] and writes the result to x[rd]. Compressed form: c.and rd, rs2
31 25 24 20 19 15 14 12 11 7 6 0
andi rd, rs1, immediate x[rd] = x[rs1] & sext(immediate) AND Immediate. I-type, RV32I and RV64I.
Computes the bitwise AND of the sign-extended immediate and register x[rs1] and writes the result to x[rd].
Compressed form: c.andi rd, imm
31 20 19 15 14 12 11 7 6 0
auipc rd, immediate x[rd] = pc + sext(immediate[31:12] << 12) Add Upper Immediate to PC. U-type, RV32I and RV64I. Adds the sign-extended 20-bit immediate, left-shifted by 12 bits, to the pc, and writes the result to x[rd]. 31 1211 76 0 7 6 0 00100 aq rl rs2 rs1 010 rd 0101111 x[rd] = x[rs1] & x[rs2] 0000000 rs2 rs1 111 rd 0110011 immediate[11:0] rs1 111 rd 0010011 immediate[31:12] rd 0010111 124 RISC-V INSTRUCTIONS: BEQ beq rs1, rs2, offset if (rs1 == rs2) pc += sext(offset) Branch if Equal. B-type, RV32I and RV64I. If register x[rs1] equals register x[rs2], set the pc to the current pc plus the sign-extended offset. Compressed form: c.beqz rs1, offset 31 25 24 20 19 15 14 12 11 7 6 0 beqz rs1, offset if (rs1 == 0) pc += sext(offset) Branch if Equal to Zero. Pseudoinstruction, RV32I and RV64I. Expands to beq rs1, x0, offset. bge rs1, rs2, offset if (rs1 ≥s rs2) pc += sext(offset) Branch if Greater Than or Equal. B-type, RV32I and RV64I. If register x[rs1] is at least x[rs2], treating the values as two’s complement numbers, set the pc to the current pc plus the sign-extended offset. 31 25 24 20 19 15 14 12 11 7 6 0 bgeu rs1, rs2, offset if (rs1 ≥u rs2) pc += sext(offset) Branch if Greater Than or Equal, Unsigned. B-type, RV32I and RV64I. If register x[rs1] is at least x[rs2], treating the values as unsigned numbers, set the pc to the current pc plus the sign-extended offset. 31 25 24 20 19 15 14 12 11 7 6 0 bgez rs1, offset if (rs1 ≥s 0) pc += sext(offset) Branch if Greater Than or Equal to Zero. Pseudoinstruction, RV32I and RV64I. Expands to bge rs1, x0, offset. bgt rs1, rs2, offset if (rs1 >s rs2) pc += sext(offset) Branch if Greater Than. Pseudoinstruction, RV32I and RV64I.
Expands to blt rs2, rs1, offset.
bgtu rs1, rs2, offset if (rs1 >u rs2) pc += sext(offset) Branch if Greater Than, Unsigned. Pseudoinstruction, RV32I and RV64I.
Expands to bltu rs2, rs1, offset.
offset[12|10:5]
rs2
rs1
000
offset[4:1|11]
1100011
offset[12|10:5]
rs2
rs1
101
offset[4:1|11]
1100011
offset[12|10:5]
rs2
rs1
111
offset[4:1|11]
1100011

RISC-V INSTRUCTIONS: BLTU 125
bgtz rs2, offset if (rs2 >s 0) pc += sext(offset) Branch if Greater Than Zero. Pseudoinstruction, RV32I and RV64I.
Expands to blt x0, rs2, offset.
ble rs1, rs2, offset if (rs1 ≤s rs2) pc += sext(offset) Branch if Less Than or Equal. Pseudoinstruction, RV32I and RV64I.
Expands to bge rs2, rs1, offset.
bleu rs1, rs2, offset if (rs1 ≤u rs2) pc += sext(offset) Branch if Less Than or Equal, Unsigned. Pseudoinstruction, RV32I and RV64I.
Expands to bgeu rs2, rs1, offset.
blez rs2, offset if (rs2 ≤s 0) pc += sext(offset) Branch if Less Than or Equal to Zero. Pseudoinstruction, RV32I and RV64I.
Expands to bge x0, rs2, offset.
blt rs1, rs2, offset if (rs1 >s uimm
>>u uimm
100
uimm[5]
01
rd′
uimm[4:0]
01
100
uimm[5]
00
rd′
uimm[4:0]
01
c.sub rd′, rs2′
Subtract. RV32IC and RV64IC.
Expands to sub rd, rd, rs2, where rd=8+rd′ and rs2=8+rs2′.
x[8+rd′] = x[8+rd′] – x[8+rs2′] 15 109 76 54 21 0
100011
rd′
00
rs2′
01
c.subw rd′, rs2′ x[8+rd′] = sext((x[8+rd′] – x[8+rs2′])[31:0]) Subtract Word. RV64IC only.
Expands to subw rd, rd, rs2, where rd=8+rd′ and rs2=8+rs2′.
15 109 76 54 21 0
c.sw rs2′, uimm(rs1′) M[x[8+rs1′] + uimm][31:0] = x[8+rs2′] Store Word. RV32IC and RV64IC.
Expands to sw rs2, uimm(rs1), where rs2=8+rs2′ and rs1=8+rs1′.
15 1312 109 76 54 21 0
c.swsp rs2, uimm(x2) M[x[2] + uimm][31:0] = x[rs2] Store Word, Stack-Pointer Relative. RV32IC and RV64IC.
Expands to sw rs2, uimm(x2).
15 1312 76 21 0
100111
rd′
00
rs2′
01
110
uimm[5:3]
rs1′
uimm[2|6]
rs2′
00
110
uimm[5:2|7:6]
rs2
10