{"id":33,"date":"2019-11-30T01:41:00","date_gmt":"2019-11-30T06:41:00","guid":{"rendered":"https:\/\/www.vociferousvoid.org\/?p=33"},"modified":"2023-07-21T22:41:13","modified_gmt":"2023-07-22T02:41:13","slug":"risc-v-bare-metal-programming-chapter-4-another-brick-in-the-wall","status":"publish","type":"post","link":"https:\/\/www.vociferousvoid.org\/index.php\/2019\/11\/30\/risc-v-bare-metal-programming-chapter-4-another-brick-in-the-wall\/","title":{"rendered":"RISC-V Bare Metal Programming – Chapter 4: Another Brick in the Wall"},"content":{"rendered":"\n

Chapter 3<\/a> of this RISC-V bare metal tutorial studied the linking process and how a developer can control where code and data are placed in memory. Constants, initialized variables and uninitialized variables were defined and explicitly positioned in RAM as prescribed by a linker script. The running example program was updated to read operands from RAM to perform its task, and subsequently store the result in a different location in RAM. However, up to this point only the base RV64I instruction set has been used. This chapter will explore some of the standard extensions available in the RISC-V ISA.<\/p>\n\n\n\n

One of the objectives in the design of the RISC-V ISA is to support many different deployment environments which may have varying constraints for efficiency, performance, and cost. For this reason, the base instruction set was restricted to the minimum required to build a useful program. This reduces the processor complexity potentially yielding performance and efficiency gains. However, these gains may be lost when performing more complex computations. To address potential limitations in the base instruction set, optional standard extensions have been defined to expand the available set of instructions. The standard extensions available for 32 and 64-bit instruction sets include: M<\/strong> Support for multiply and divide (RV32M and RV64M). A<\/strong> Atomic operations (RV32A and RV64A). F<\/strong> Floating point support (RV32F and RV64F). D<\/strong> Double precision floating point support (RV32D and RV64D).<\/p>\n\n\n\n

This set of standard extensions are typically included in most implementations of RISC-V cores. The base set plus these extensions is often referred to as the G<\/strong> instruction set (RV32G or RV64G). Each of these standard extensions will be explored in this chapter.<\/p>\n\n\n\n

Multiply<\/h2>\n\n\n\n

The M<\/strong> extension provides instructions for multiplying and dividing integers using both word and double-word length operands. When using word length operands, the result will not require more than 64-bits of memory which fits in an RV64I registers. The following listing of the product.s<\/code> source file shows the assembly code of a function to multiply word sized integer operands:<\/p>\n\n\n\n

 1:         .text\n 2:         .align 2\n 3:         .global __imul32\n 4: __imul32:\n 5:         # Input:\n 6:         # a0: 32-bit multiplicand\n 7:         # a1: 32-bit multiplier\n 8:         # Result:\n 9:         # a0: 64-bit product\n10:         addi    sp, sp, -32\n11:         sd      ra, 24(sp)\n12:         mulw    a0, a0, a1\n13:         ld      ra, 24(sp)\n14:         addi    sp, sp, 32\n15:         ret<\/code><\/pre>\n\n\n\n
Due to the fact that the arguments of this function are expected to be word-length data, the calculation of the product can be performed using a single instruction (mulw<\/code> on line 12<\/a>). The main program can be updated as follows to invoke the __imul32<\/code> function:<\/p>\n\n\n\n
 1:         .section \".text.init\"\n 2:         .align 2\n 3:         .global _start\n 4:         .global _stack_end\n 5: _start:\n 6:         lw      a0, operand1\n 7:         lw      a1, operand2\n 8:         la      sp,_stack_end\n 9:         call    sum\n10:         la      t1, result1\n11:         sw      a0, 0(t1)\n12:         call    __imul32\n13:         la      t1, result2\n14:         sd      a0, 0(t1)\n15: stop:   j       stop\n16:         .section \".rodata\"\n17: operand1:       .word   4\n18:         .data\n19: operand2:       .word   5\n20:         .bss\n21: result1:        .word   0\n22: result2:        .dword  0<\/code><\/pre>\n\n\n\n
The .bss<\/code> section of the ELF file was updated to declare two result variables: result1<\/code> on line 21<\/a> which will hold the sum of the operands in a word, and result2<\/code> on line 22<\/a> which will hold their product in a double-word.<\/p>\n\n\n\n
After the sum of the operands is calculated, and the result is saved in memory, it is kept in register a0<\/code> to be used as the multiplicand. The value of operand2<\/code> will be used as the multiplier; its value should still be in the a1<\/code> register since its content is not modified by the sum<\/code> function. The __imul32<\/code> function is then called on line 12<\/a> and the result is saved in memory at line 14<\/a>.<\/p>\n\n\n\n
The program can be compiled and executed in QEMU<\/kbd> using the following sequence of commands:<\/p>\n\n\n\n
riscv64-unknown-elf-as -o add.o add.s\nriscv64-unknown-elf-as -o main.o main.s\nriscv64-unknown-elf-as -o product.o product.s\nriscv64-unknown-elf-ld -T chapter3.lds -o main.elf add.o main.o product.o\nqemu-system-riscv64 -M virt -serial \/dev\/null -nographic -kernel main.elf\nQEMU 3.1.0 monitor - type 'help' for more information\n(qemu) <\/code><\/pre>\n\n\n\n
The chapter3.lds<\/code> linker script is the same one that was used in chapter 3. The result values can be inspected from the QEMU console using the xp<\/kbd> command:<\/p>\n\n\n\n
(qemu) xp \/1wd 0x80001004\n0000000080001004:          9\n(qemu) xp \/1gd 0x80001008\n0000000080001008:         45\n(qemu) <\/code><\/pre>\n\n\n\n
The location of result1<\/code> in memory is the same as result<\/code> from the previous chapter. The memory location of result2<\/code> will be 4-bytes beyond result1<\/code> since this value is 32-bits wide. Therefore the product result can be found at memory offset 0x80001008<\/code>. This can easily be verified using the objdump<\/kbd> utility:<\/p>\n\n\n\n
$ riscv64-unknown-elf-objdump -D -j.bss main.elf \n\nsum.elf:     file format elf64-littleriscv\n\n\nDisassembly of section .bss:\n\n0000000080001004 <result1>:\n    80001004:\t0000                \tunimp\n\t...\n\n0000000080001008 <result2>:\n\t...\n<\/code><\/pre>\n\n\n\n
As expected the multiplication of 9 and 5 is 45.<\/p>\n\n\n\n
Multiplication using registers is a little more complicated when dealing with 64-bit values. This is due to the fact that the product will be wider (in bits) than either the multiplier or multiplicand. The __imul32<\/code> function assumes that the operands are word-length values, therefore the result will fit in a single double-word register. However, the calculated product will be truncated if double-word length operands are provided. The product of two 64-bit values may have as many as 128 bits which is wider than any available register in the RV64I instruction set. To mitigate this problem, the RISC-V ISA requires two instructions to perform a multiplication: one to calculate the most significant double-word (mulh<\/code>), and a second to calculate the least significant double-word (mul<\/code>). The following listing illustrates the __imul64<\/code> function that can handle 64-bit operands:<\/p>\n\n\n\n
 1:         .global __imul64\n 2: __imul64:\n 3:         # Input:\n 4:         # a0: 64-bit multiplicand\n 5:         # a1: 64-bit multiplier\n 6:         # Result:\n 7:         # a0: low 64-bits of the product\n 8:         # a1: high 64-bits of the product\n 9:         addi    sp, sp, -32\n10:         sd      ra, 24(sp)\n11:         sd      t1, 16(sp)\n12:         sd      t0, 8(sp)\n13:         mv      t0, a0\n14:         mv      t1, a1\n15:         mul     a0, t0, t1\n16:         mulh    a1, t0, t1\n17:         ld      t0, 8(sp)\n18:         ld      t1, 16(sp)\n19:         ld      ra, 24(sp)\n20:         addi    sp, sp, 32\n21:         ret<\/code><\/pre>\n\n\n\n
This code can be added to the product.s<\/code> source file to provide a multiplication operation that uses 64-bit integers. The first thing this function does is save the contents of registers t1<\/code> (line 11<\/a>) and t0<\/code> (line 12<\/a>) which will be used by this function.<\/p>\n\n\n\n
\n
Note<\/strong>: these are supposed to be caller saved registers, presumably the caller of the product function would have saved them. However, we are saving them here anyway<\/p>\n<\/blockquote>\n\n\n\n
The values of the function arguments are then moved into the temporary registers (lines 13<\/a> and 14<\/a>). This is required because, unlike the first version of this function, the arguments need to be reused and the value of a0<\/code> will be overwritten by the first mutiplication on line 15<\/a> which calculates the product of the low 32-bits of the operands. The second multiplication (line 1<\/a>6<\/a>) will calculate the product of the high 32-bits of the operands and store the result in a1<\/code>.<\/p>\n\n\n\n
The main program must be updated to handle a potential 128-bit result from the __imul64<\/code> function:<\/p>\n\n\n\n
 1:         .section \".text.init\"\n 2:         .align 2\n 3:         .global _start\n 4:         .global _stack_end\n 5: _start:\n 6:         lw      a0, operand2\n 7:         lw      a1, operand1\n 8:         la      sp,_stack_end\n 9:         call    sum\n10:         la      t1, result1\n11:         sw      a0, 0(t1)\n12:         call    __imul64\n13:         la      t1, result2\n14:         sd      a0, 8(t1)\n15:         sd      a1, 0(t1)\n16: stop:   j       stop\n17:         .section \".rodata\"\n18: operand1:       .word   4\n19:         .data\n20: operand2:       .word   5\n21:         .bss\n22: result1:        .word   0\n23: result2:        .dword  0, 0<\/code><\/pre>\n\n\n\n
The most significant change is that the result must be stored to memory using two instructions: one to store the product of the low 32-bits (line 14<\/a>), and one to store the product of the high 32-bits (line 15<\/a>). The result2<\/code> variable on line 23<\/a> must also be updated to reserve 128-bits for the product. The arguments of the __imul64<\/code> function are the same as those of the __imul32<\/code> function. Therefore the new function can be invoked by simply changing the call label on line 12<\/a>.<\/p>\n\n\n\n
After recompiling and linking the modified source files, the result can be inspecetd in the QEMU console by printing out 2 double-word values at offset 0x80001008<\/code>:<\/p>\n\n\n\n
$ qemu-system-riscv64 -M virt -serial \/dev\/null -nographic -kernel main.elf\nQEMU 3.1.0 monitor - type 'help' for more information\n(qemu) xp \/2gd 0x80001008\n0000000080001008:                   45                    0\n(qemu) quit\n<\/code><\/pre>\n\n\n\n
Note that the __imul64<\/code> function can also be used with 32-bit operands. The value of the high double-word will be zero in this case since no overflow occurred.<\/p>\n\n\n\n
Divide<\/h2>\n\n\n\n
The RVM<\/strong> extension also provides instructions to calculate the quotient and remainder a division of an integer by another integer. This is slightly less complicated than multiplication because the result cannot be wider than the operands. However, this also limits divisions to dividends and divisors with a maximum of 64-bits. Therefore this is not a true reciprocal of the multiplication which can have a 128-bit result.<\/p>\n\n\n\n
The following listing illustrates the contents of the divide.s<\/code> source file which defines the function to divide an unsigned 64-bit integer divisor by an unsigned 64-bit integer dividend.<\/p>\n\n\n\n
 1:         .text\n 2:         .align 2\n 3:         .global __idiv64u\n 4: __idiv64u:\n 5:         addi    sp, sp, -32\n 6:         sd      ra, 24(sp)\n 7:         beqz    a1, __idiv64u_exit\n 8:         div     a0, a0, a1\n 9: __idiv64u_exit: \n10:         ld      ra, 24(sp)\n11:         addi    sp, sp, 32\n12:         ret<\/code><\/pre>\n\n\n\n
This function is fairly straight forward, after ensuring that the dividend is not zero, it simply calls the div<\/code> instruction to calculate the quotient. The check to ensure that the dividend is not zero on line 7<\/a> is necessary because R64M<\/strong> does not trap on a divide by zero error. If the dividend is zero, the div<\/code> instruction will be skipped.<\/p>\n\n\n\n
Since the result of the __imul64<\/code> function is a 64-bit value due to its small operands, the __idiv64<\/code> function can be invoked on the result to verify its accuracy. The main.s<\/code> program can be updated as follows to divide the result of __imul64<\/code> by operand2<\/code>, and save the result in a variable in the .data<\/code> section named result3<\/code>.<\/p>\n\n\n\n
 1:         .section \".text.init\"\n 2:         .align 2\n 3:         .global _start\n 4:         .global _stack_end\n 5: _start:\n 6:         lw      a0, operand1\n 7:         lw      a1, operand2\n 8:         la      sp,_stack_end\n 9:         call    sum\n10:         la      t1, result1\n11:         sw      a0, 0(t1)\n12:         call    __imul64\n13:         la      t1, result2\n14:         sd      a0, 0(t1)\n15:         sd      a1, 8(t1)\n16:         bnez    a1, stop\n17:         lw      a1, operand2\n18:         call    __idiv64u\n19:         la      t0, result3\n20:         sd      a0, 0(t0)\n21: stop:   j       stop\n22:         .section \".rodata\"\n23: operand1:       .word   4\n24:         .data\n25: operand2:       .word   5\n26:         .bss\n27: result1:        .word   0\n28: result2:        .dword  0, 0\n29: result3:        .dword  0<\/code><\/pre>\n\n\n\n
After __imul64<\/code> returns, the value is checked for overflow (line 16<\/a>) by asserting that the value returned in a1<\/code> is zero. This will ensure that the result of the multiplication fits in a single 64-bit register. If the result is greater than 64-bits wide, the division will be skipped. Otherwise operand2<\/code> is loaded into register a1<\/code>. This check is not strictly necessary unless different operand values are used which may result in an overflow.<\/p>\n\n\n\n
The divide function will determine the quotient of the __imul64<\/code> result by the value of operand2<\/code>. The quotient will be stored in the result3<\/code> variable. This should be the same as the result of the sum<\/code> function (in result1<\/code>). This can be verified by assembling and linking this program and running the binary in QEMU. The value of result3<\/code><\/p>\n\n\n\n
riscv64-unknown-elf-as -o add.o add.s\nriscv64-unknown-elf-as -o divide.o divide.s\nriscv64-unknown-elf-as -o main.o main.s\nriscv64-unknown-elf-as -o product.o product.s\nriscv64-unknown-elf-ld -T chapter3.lds -o main.elf add.o divide.o main.o product.o\nqemu-system-riscv64 -M virt -serial \/dev\/null -nographic -kernel main.elf\nQEMU 3.1.0 monitor - type 'help' for more information\n(qemu) xp \/1wd 0x80001004\n0000000080001004:          9\n(qemu) xp \/1gd 0x80001018\n0000000080001018:                    9\n(qemu) <\/code><\/pre>\n\n\n\n
The offset of the result3<\/code> variable will be 0x80001018<\/code>; it is 16-bytes beyond the result2<\/code> variable which is located at 0x80001008<\/code> (therefore +0x10<\/code>). This can be verified using objdump<\/kbd> as in the previous example.<\/p>\n\n\n\n
As expected, result3<\/code> contains the integer 9 which is the result of the sum<\/code> function in variable result1<\/code> at offset 0x80001004<\/code>.<\/p>\n\n\n\n
This value is convenient because 5 divides 45 exactly. If we divided the result of __imul64<\/code> by operand1<\/code> instead, the result would be 11 and there would be a remainder of 1. In the current implementation, this value is lost. However, the divide function can be updated to calculate the quotient and the remainder of a division. The updated __idiv64u<\/code> function is illustrated in the following listing.<\/p>\n\n\n\n
 1: __idiv64u:\n 2:         # Input:\n 3:         # a0: 64-bit divisor\n 4:         # a1: 64-bit dividend\n 5:         # Returns:\n 6:         # a0 => 64-bit quotient\n 7:         # a1 => 64-bit remainder\n 8:         addi    sp, sp, -32\n 9:         sd      ra, 24(sp)\n10:         sd      t1, 16(sp)\n11:         sd      t0, 8(sp)\n12:         beqz    a1, __idiv64u_exit\n13:         mv      t0, a0\n14:         mv      t1, a1\n15:         div     a0, t0, t1\n16:         rem     a1, t0, t1\n17: __idiv64u_exit: \n18:         ld      t0, 8(sp)\n19:         ld      t1, 16(sp)\n20:         ld      ra, 24(sp)\n21:         addi    sp, sp, 32\n22:         ret<\/code><\/pre>\n\n\n\n
This new implementation will save the argument values in temporary registers because this is a two-step function and the first argument would be overridden in the first step. The divide<\/code> function then calculates the quotient on line 15<\/a>, and the remainder on line 16<\/a>. The main.s<\/kbd> program must also be updated to save the result of the new divide<\/code> function in two double words.<\/p>\n\n\n\n
 1:         .section \".text.init\"\n 2:         .align 2\n 3:         .global _start\n 4:         .global _stack_end\n 5: _start:\n 6:         lw      a0, operand1\n 7:         lw      a1, operand2\n 8:         la      sp,_stack_end\n 9:         call    sum\n10:         la      t1, result1\n11:         sw      a0, 0(t1)\n12:         call    __imul64\n13:         la      t1, result2\n14:         sd      a0, 0(t1)\n15:         sd      a1, 8(t1)\n16:         bnez    a1, stop\n17:         lw      a1, operand1\n18:         beqz    a1, stop\n19:         call    __idiv64u\n20:         la      t0, result3\n21:         sd      a0, 0(t0)\n22:         sd      a1, 8(t0)\n23: stop:   j       stop\n24:         .section \".rodata\"\n25: operand1:       .word   4\n26:         .data\n27: operand2:       .word   5\n28:         .bss\n29: result1:        .word   0\n30: result2:        .dword  0, 0\n31: result3:        .dword  0, 0<\/code><\/pre>\n\n\n\n
The only changes are that operand1<\/code> is used as the dividend on line 17<\/a> and an instruction was added on line 22<\/a> to store the remainder in RAM. The result3<\/code> variable was also updated to allocate two double-words of memory on line 31<\/a>. If this program is assembled and linked, then executed in QEMU (as in the previous example), the contents of operand3<\/code> can be inspected to see that both the quotient and remainder have been calculated:<\/p>\n\n\n\n
(qemu) xp \/2gd 0x80001018\n0000000080001018:                   11                    1<\/code><\/pre>\n\n\n\n
This provides a more flexible implementation of __idiv64u<\/code>, but if a true reciprocal of the __imul64<\/code> function is desired, the function must allow for a 128-bit divisor argument. The RV64M<\/strong> extension does not define an instruction to calculate this, therefore the calculation must be performed in parts.<\/p>\n\n\n\n
If the 128-bit divisor is broken up into four words, the division can be carried out on each part individually and the result combined. This is possible because of the following:<\/p>\n\n\n\n
$$ x=2^{32}w_h+w_l $$<\/p>\n\n\n\n
The quotient of x<\/em> by some integer d<\/em> can be calculated as:<\/p>\n\n\n\n
$$ \\frac{x}{d}=\\frac{2^{32}w_h}{d} + \\frac{2^{32}w_h \\mod({d+w_l)}}{d} $$<\/p>\n\n\n\n
This calculation can be implemented with the following RISC-V assembly code:<\/p>\n\n\n\n
 1:         .global __idiv128u\n 2: __idiv128u:\n 3:         # Input:\n 4:         # a0: Address where the 128-bit quotient will be stored (high\n 5:         #     dword, low dword).\n 6:         # a1: 64-bit dividend\n 7:         # a2: Address of the 128-bit divisor (high dword, low dword)\n 8:         # Returns:\n 9:         # a0: Address of the 128-bit quotient\n10:         # a1: 64-bit remainder\n11:         addi    sp, sp, -32\n12:         sd      ra, 24(sp)\n13:         # Check for divide by zero\n14:         beqz    a1, __idiv128u_exit\n15:         addi    t2, a2, 16\n16:         li      t3, 0           # t3 = remainder\n17: __idiv128u_next_dword:\n18:         lwu     t1, (a2)        # t1 = low word\n19:         ld      t0, (a2)\n20:         srli    t0, t0, 32      # t0 = high word\n21: __idiv128u_high_word:\n22:         slli    t3, t3, 32      \n23:         add     t0, t0, t3\n24:         divu    t4, t0, a1      # t4 = t0\/a1\n25:         slli    t5, t4, 32      # t5 = t4 * 2^32\n26:         remu    t3, t0, a1      # t3 = t0 mod a1\n27: __idiv128u_low_word:\n28:         slli    t3, t3, 32      # t3 = t3 * 2^32\n29:         add     t0, t1, t3\n30:         divu    t4, t0, a1\n31:         add     t5, t5, t4\n32:         remu    t3, t0, a1\n33:         sd      t5, (a0)\n34:         addi    a2, a2, 8\n35:         addi    a0, a0, 8\n36:         bne     t2, a2, __idiv128u_next_dword\n37:         mv      a0, t3\n38: __idiv128u_exit:        \n39:         ld      ra, 24(sp)\n40:         addi    sp, sp, 32\n41:         ret<\/code><\/pre>\n\n\n\n
This function iteratively performs a 64-bit division on 32-bit words of the divisor. The remainder is scaled (28<\/a>), then added to the next word of the divisor (line 29<\/a>) and the process is repeated for the next 64-bit double word.<\/p>\n\n\n\n
The following listing illustrates an updated main.s<\/code> file:<\/p>\n\n\n\n
 1:         .section \".text.init\"\n 2:         .align 2\n 3:         .global _start\n 4:         .global _stack_end\n 5: _start:\n 6:         lw      a0, operand1\n 7:         lw      a1, operand2\n 8:         la      sp, _stack_end\n 9:         call    sum\n10:         la      t1, result1\n11:         sw      a0, 0(t1)\n12:         call    __imul64\n13:         la      t1, divisor\n14:         sd      a0, 8(t1)\n15:         sd      a1, 0(t1)\n16:         la      a0, quotient\n17:         lw      a1, operand1\n18:         la      a2, divisor\n19:         call    __idiv128u\n20:         la      t0, remainder\n21:         sd      a0, (t0)\n22: stop:   j       stop\n23:         .section \".rodata\"\n24: operand1:       .word   4\n25:         .data\n26: operand2:       .word   5\n27:         .bss\n28: result1:        .word   0\n29: result2:        .dword  0, 0\n30: result3:        .dword  0, 0\n31: divisor:        .dword  0, 0\n32: quotient:       .dword  0, 0\n33: remainder:      .dword  0<\/code><\/pre>\n\n\n\n
This updated main program does not perform an overflow check since the __idiv128u<\/code> function can handle a 128-bit divisor. This function also reads its operands directly from memory rather than from registers due to the fact that the divisor may not fit in a single register. The memory at label quotient<\/code> will be updated with the result of the division. The remainder will be returned by the function, which is then saved to the memory at label remainder<\/code> on line 20<\/a>.<\/p>\n\n\n\n
Atomic Instructions<\/h2>\n\n\n\n
Synchronization is an important feature in multiprocessing systems. Thus far, the examples have used a single hardware thread, or hart, therefore there has not been any need to synchronize memory access. RISC-V defines the A<\/strong> extension which provides instructions to atomically read-modify-write data in memory. These instructions can be used to support synchronization between multiple hardware threads running in the same memory space.<\/p>\n\n\n\n
The most basic synchronization primitive is the atomic compare and swap operation. This will compare a value in a register with a value in memory. If the two values are equal, the value in another register will be swapped with the value in memory. The pseudo code for this is as follows:<\/p>\n\n\n\n
    \n
  1. Load value in register R1<\/strong><\/li>\n\n\n\n
  2. Load address of the second value in R2<\/strong><\/li>\n\n\n\n
  3. Load the value at address R2<\/strong> into a temporary register T1<\/strong><\/li>\n\n\n\n
  4. Load swap value in register R3<\/strong><\/li>\n\n\n\n
  5. If R1<\/strong> == T1<\/strong>:\n
      \n
    1. Store R3<\/strong> at memory location R2<\/strong><\/li>\n\n\n\n
    2. R3<\/strong> := T1<\/strong><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n\n\n\n
      This entire sequence is expected to be performed atomically (i.e. there can be no interrupt between the time the value T1<\/strong> is read from memory, and the end of the procedure. This can be implemented using Load Reserved\/Store Conditional instructions provided by the RVA<\/strong> extension. The following listing illustrates the implementation of a compare-and-swap function:<\/p>\n\n\n\n
       1:         .text\n 2:         .align 2\n 3:         .global compare_and_swap\n 4:         # a0: Address of value operand\n 5:         # a1: Value to compare\n 6:         # a2: Value to swap if (a0) == a1\n 7:         # return: a0 == 0 => CAS successful\n 8:         # return: a0 == 1 => CAS failed\n 9: compare_and_swap:\n10:         lr.d    t0, (a0)\n11:         bne     t0, a1, nomatch\n12:         sc.d    a0, a2, (a0)\n13:         bnez    a0, compare_and_swap\n14:         j       exit\n15: nomatch:\n16:         li      a0, 1\n17: exit:\n18:         ret<\/code><\/pre>\n\n\n\n
      This function will atomically compare the value in memory located at the address in a0<\/code> with the value in register a1<\/code>, and store the value of a2<\/code> at the location in a0<\/code> if they match.<\/p>\n\n\n\n
      The load-reserved instruction on line 10<\/a> loads the value at memory location a0<\/code> into register t0<\/code>, and registers a reservation on the address in memory. The nature of the memory reservation is specific to the implementation of the RISC-V core and is transparent to the program. The memory range that is reserved can be arbitrarily sized, however, it must be at least large enough to enclose the value that was loaded.<\/p>\n\n\n\n
      The value of t0<\/code> is then compared with a1<\/code>. If the values match, the store-conditional instruction on line 12<\/a> will save the value in a2<\/code> to the memory location of a0<\/code>. This will also release the reservation on the memory address. If the values do not match, the memory is not updated (this instruction is skipped).<\/p>\n\n\n\n
      If another hardware thread writes data to the memory for which there is a reservation, then the store-conditional instruction will fail and a non-zero error code will be written to the destination register which is a0<\/code> in this function (line 12<\/a>. In this case, the compare-and-swap operation is restarted (line 13<\/a>.<\/p>\n\n\n\n
      The main program shown in the following listing will invoke the compare-and-swap function:<\/p>\n\n\n\n
       1:         .section \".text.init\"\n 2:         .align 2\n 3:         .global _start\n 4:         .global _stack_end\n 5: _start:\n 6:         la      sp, _stack_end\n 7:         la      a0, n\n 8:         li      a1, 5\n 9:         li      a2, 6\n10:         call    compare_and_swap\n11:         la      a0, n\n12:         li      a1, 5\n13:         li      a2, 7\n14:         call    compare_and_swap\n15: stop:   j       stop\n16:         .balign 8\n17: n:              .dword  5\n<\/code><\/pre>\n\n\n\n
      Starting at line 7<\/a>, the function arguments are setup by first loading the address of the variable n<\/code> into a0<\/code>. Note that the alignment of the data loaded by the lr.d<\/code> instruction must be aligned on an 8-byte boundary (similarly the lr.w<\/code> instruction expects the data to be aligned to a 4-byte boundary). The .balign<\/code> (byte align) assembler directive on line 16<\/a> ensures that this is the case.<\/p>\n\n\n\n
      The first invocation of the function on line 10<\/a> will succeed, thus the value of n<\/code> will be updated to 6. the second invocation will fail, this the value of n<\/code> will not be changed. This can be verified by assembling the program and inspecting the memory from the QEMU monitor:<\/p>\n\n\n\n
      riscv64-unknown-elf-as  -o chapter4_cas_main.o chapter4_cas_main.s\nriscv64-unknown-elf-as  -o cas.o cas.s\nriscv64-unknown-elf-ld -T chapter3.lds -o chapter4-cas.elf chapter4_cas_main.o cas.o\nqemu-system-riscv64 -M virt -serial \/dev\/null -nographic -kernel chapter4-cas.elf\nQEMU 3.1.0 monitor - type 'help' for more information\n(qemu) xp \/1gd 0x80001008\n0000000080001008:                    6\n(qemu) \n<\/code><\/pre>\n\n\n\n
      In addition to the load-reserved\/store-conditional instructions, the RVA<\/strong> extension also provides atomic memory operations. These atomically perform an operation on a value in memory, and swap the previous content of the memory location into the targetted register. The supported operations include: add<\/code>, and<\/code>, or<\/code>, xor<\/code>, max<\/code>, min<\/code>, and swap<\/code>. Moreover, the min<\/code> and max<\/code> instructions have signed and unsigned variants. These instructions are convenient for defining another useful synchronization primitive: the test-and-set spinlock.<\/p>\n\n\n\n
      Spinlocks can be acquired by setting a sentinel value in a specific memory location, but only if that value is not already set therein. If the target memory location already contains the sentinel value, the spinlock will loop until it is released. The lock is released by clearing the memory location (i.e. setting it to zero). The implementation of a spinlock acquire\/release pair is illustrated in the listing that follows:<\/p>\n\n\n\n
       1:         .text\n 2:         .align 2\n 3:         .global spinlock_acquire\n 4: spinlock_acquire:\n 5:         # a0 = memory address of the spinlock\n 6:         li      t1, 1 #\n 7:         amoswap.d.aq    t0, t1, (a0) #\n 8:         bnez    t1, spinlock_acquire #\n 9:         ret\n10: \n11:         .global spinlock_release\n12: spinlock_release:\n13:         # a0 = memory address of the spinlock\n14:         amoswap.d.rl zero, zero, (a0) #\n15:         ret\n16: \n<\/code><\/pre>\n\n\n\n
      This listing defines two sub-routines: one to acquire a spinlock, and one to release it. The spinlock_acquire<\/code> function loads the value 1 to use as the sentinel on line 6<\/a>. Then the atomic memory operation amoswap<\/code> is used on line 7<\/a> to swap the value of the sentinel with the contents of the memory location specified in a0<\/code>. The value contained in the lock location will be saved in register t0<\/code>. If this value is not zero, the lock was already acquired by another thread, therefore the function will try again (line 8<\/a>), otherwise the function returns.<\/p>\n\n\n\n
      the spinlock<\/code> release function will simply write zero into the memory location specified in a0<\/code>. This will allow another thread that is spinning on the lock to acquire it.<\/p>\n\n\n\n
      The amoswap<\/code> instruction has two variants: one for double-words (amoswap.d<\/code>) and one for word values (amoswap.w<\/code>). Moreover, there are flags which define define the release consistency semantics of the memory operation (the .aq<\/code> and .rl<\/code> suffixes). Basically by setting the .aq<\/code> suffix on the operation, then the effect of memory operations that occur after this one in the current hardware thread will not be observed by another thread before the effect of the current instruction. Conversely, when the .rl<\/code> suffix is specified, the effects of memory operations preceding that of the current instruction will not be observed by other threads after its own effect.<\/p>\n\n\n\n
      The following program illustrates the use of the spinlock functions to define a critical section:<\/p>\n\n\n\n
       1:         .section \".text.init\"\n 2:         .align 2\n 3:         .global _start\n 4:         .global _stack_end\n 5: _start:\n 6:         la      sp, _stack_end\n 7:         la      a0, lock #\n 8:         call    spinlock_acquire #\n 9:         la      t0, n #\n10:         ld      a0, (t0)\n11:         li      a1, 1\n12:         call    sum\n13:         la      t0, n\n14:         sd      a0, (t0) #\n15:         la      a0, lock\n16:         call    spinlock_release #\n17: stop:   j       stop\n18:         .data\n19:         .balign 8\n20: lock:   .dword  0\n21: n:      .dword 0\n22: \n<\/code><\/pre>\n\n\n\n
      This program will attempt to acquire the spinlock on line 8<\/a> (the address of the lock variable is loaded on line 7<\/a>). This function call will block until the lock is acquired. Since there is only a single hardware thread, the lock should be acquired immediately. The critical section starts on line 9<\/a>. The variable n<\/code> is loaded and incremented by calling the sum<\/code> function (defined in a previous chapter). The critical section ends on line 14<\/a>, at which point the program releases the spinlock (16<\/a>. Following the execution of this program, the contents of the variable n<\/code> should be 1:<\/p>\n\n\n\n
      riscv64-unknown-elf-as  -o chapter4_spinlock_main.o chapter4_spinlock_main.s\nriscv64-unknown-elf-as  -o spinlock.o spinlock.s\nriscv64-unknown-elf-as  -o add.o add.s\nriscv64-unknown-elf-ld -T chapter3.lds -o chapter4-spinlock.elf chapter4_spinlock_main.o spinlock.o add.o\nqemu-system-riscv64 -M virt -serial \/dev\/null -nographic -kernel chapter4-spinlock.elf\nQEMU 3.1.0 monitor - type 'help' for more information\n(qemu) xp \/1gd 0x80001008\n0000000080001008:                    1\n\n<\/code><\/pre>\n\n\n\n
      Floating Point<\/h2>\n\n\n\n
      In chapter 2<\/a>, the base set of the base I<\/strong> (integer) registers were enumerated. However, when inspecting the VirtIO machine in QEMU, using the info registers<\/code> command, certain registers were listed that are not described in the table. These registers exist to support the F<\/strong> or D<\/strong> extensions which provide floating point arithmetic instructions that work with operands which conform to the IEEE 754-2008 standard. The F<\/strong> extension provides support for single-precission values and operands, and the D<\/strong> extension provides the same instructions for double-precision values.<\/p>\n\n\n\n
      The 32 additional registers, f0<\/code>–f31<\/code>, are used exclusively by the instructions provided by the RVF<\/strong> and RVD<\/strong> extensions. This doubles the number of registers available to the processor without increasing the space required for the register specifier in the instruction op-code since only enough bits to enumerate 32 registers are required (5 bits).<\/p>\n\n\n\n
      If only the RVF<\/strong> extension is supported, the f<\/code> registers will be 32-bits wide. If the RVD<\/strong> extension is supported, the f<\/code> registers will be 64-bits wide. If both RVF<\/strong> and RVD<\/strong> are supported, the RVF<\/strong> instructions will use only the lower 32-bits of the 64-bit registers.<\/p>\n\n\n\n
      The f<\/code> registers are enumerated in the following table with their ABI name and a description:<\/p>\n\n\n\n
      Register(s)<\/th>ABI Name(s)<\/th>Description<\/th><\/tr><\/thead>
      f0-f7<\/td>ft0-ft7<\/td>Temporary<\/td><\/tr>
      f8-f9<\/td>fs0-fs1<\/td>Saved register<\/td><\/tr>
      f10-f11<\/td>fa0-fa1<\/td>Function argument\/Return value<\/td><\/tr>
      f12-f17<\/td>fa2-fa7<\/td>Function argument<\/td><\/tr>
      f18-f27<\/td>fs2-fs11<\/td>Saved register<\/td><\/tr>
      f28-f31<\/td>ft8-ft9<\/td>Temporary<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      These registers roughly mirror the base integer registers with two notable exception: unlike x0<\/code>, f0<\/code> is not hardwired to 0<\/code>, it can be used just like every other register. Moreover there are no registers to manage return addresses, stacks, globals, or threads. The equivalent f<\/code> registers are used as temporaries.<\/p>\n\n\n\n
      The convention for who is responsible for saving the contents of the registers is essentially the same as the equivalent base integer registers: Saved registers and temporary registers are to be saved by the callee. All other registers must be saved by the caller.<\/p>\n\n\n\n
      In addition to the 32 f<\/code> registers, the RVF<\/strong> and RVD<\/strong> extensions define a status and control register: fcsr<\/code>. The RVF<\/strong> and RVD<\/strong> extensions provide the frcsr<\/code> instruction to read this register, storing its value into the targetted integer register. Similarly, the fscsr<\/code> instruction will copy the original value of fcsr<\/code> into the destination integer register, and the write the value in the source integer register thereto.<\/p>\n\n\n\n
      The fcsr<\/code> prescribes the rounding mode used by floating point operations. The rounding mode field occupies bits 5-7 of the register. The RVF<\/strong> and RVD<\/strong> extensions also define the frrm<\/code> instruction to retrieve the rounding mode.<\/p>\n\n\n\n
      The fcsr<\/code> register also contains flags to indicate exception conditions that may have occured while executing floating-point arithmetic since it was last reset. These errors include:NV Invalid operation (fcsr<\/code>[4]) DZ<\/code> Divide by zero (fcsr<\/code>[3]) OF<\/code> Overflow (fcsr<\/code>[2]) UF<\/code> Underflow (fcsr<\/code>[1]) NX<\/code> Inexact (fcsr<\/code>[0])<\/p>\n\n\n\n
      The floating-point exception flags can also be retrieved using the frflags<\/code> instruction which saves their state in the specified integer registers.<\/p>\n\n\n\n
      The RVF<\/strong> and RVD<\/strong> extensions define two load instructions and two store instructions. These are essentially mirrors of the base load and store instructions that use the f<\/code> registers rather than the x<\/code> integer registers. Therefore their addressing mode and format are the same as the lw<\/code>, ld<\/code>, sw<\/code> and sd<\/code> instructions.<\/p>\n\n\n\n
      The RVF<\/strong> and RVD<\/strong> extensions also provide a set of arithmetic instructions including:<\/p>\n\n\n\n