RISCV - 2 “Zicsr“, CSR Instructions
CSR：Control and Status Register
RISCV-1 RV32/64G instruction set list
RISC-V defines a separate address space of 4096 Control and Status registers associated with each hart. This chapter defines the full set of CSR instructions that operate on these CSRs. RISC-V defines a separate address space of 4096 Control and Status registers associated with each hart
. space, these registers are associated with each Hart. This chapter defines the full set of CSR instructions that operate on these CSRs.
Note: While CSRs are primarily used by the privileged architecture, there are several uses in unprivileged code including
for counters and timers, and for floating-point status.
Includes counters and timers and floating point status.
The counters and timers are no longer considered mandatory parts of the standard base ISAs
The counters and timers are no longer considered mandatory parts of the standard base ISA.
1 CSR Instructions
All CSR instructions atomically read-modify-write a single CSR, whose CSR specifier is encoded in the 12-bit csr field of the instruction held in bits 31-20. The immediate forms use a 5-bit zero-extended immediate encoded in the rs1 field.
All CSR instructions atomically read-modify-write a single CSR whose CSR indicator is encoded in the instruction's 12-bit csr field, which is located in bits 31-20. The immediate form uses a 5-bit zero-extended immediate encoded in the rs1 field.
The CSRRW (Atomic Read/Write CSR) instruction atomically swaps values in the CSRs and integer registers. CSRRW reads the old value of the CSR, zero-extends the value to XLEN bits, then writes it to integer register rd. The initial value in rs1 is written to the CSR. If rd=x0, then the instruction shall not read the CSR and shall not cause any of the side effects that might occur on a CSR read.
The CSRRW (Atomic Read/Write CSR) instruction atomically swaps the values in CSR and integer register Rd. CSRRW reads the old value of CSR, zero-extends it to the XLEN bits, and writes to integer register rd. The initial value in rs1 is written to the CSR. If rd=x0, the instruction does not read the CSR, nor does it cause any side effects that may occur when reading a CSR.
The CSRRS (Atomic Read and Set Bits in CSR) instruction reads the value of the CSR, zero-extends the value to XLEN bits, and writes it to integer register rd. The initial value in integer register rs1 is treated as a bit mask that specifies bit positions to be set in the CSR. Any bit that is high in rs1 will cause the corresponding bit to be set in the CSR, if that CSR bit is writable. Other bits in the CSR are not explicitly written. CSRRS (atomic
read Fetch and Set Number of Bits in CSR) instruction reads the value of CSR, zero-extends it to XLEN bits, and writes to integer register rd. The initial value in integer register rs1 is treated as a bitmask specifying the bit positions in the CSR to be set. If the CSR bit is writable, any high bit in rs1 will cause the corresponding bit in CSR to be set. Other bits in the CSR are not written explicitly.
The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the value of the CSR, zero-extends the value to XLEN bits, and writes it to integer register rd. The initial value in integer register rs1 is treated as a bit mask that specifies bit positions to be cleared in the CSR. Any bit that is high in rs1 will cause the corresponding bit to be cleared in the CSR, if that CSR bit is writable. Other bits in the CSR are not explicitly written. CSRRC (atomic
read Fetch and Clear Bits in CSR) instruction reads the value of CSR, zero-extends it to XLEN bits, and writes the integer register rd. The initial value in integer register rs1 is treated as a bitmask specifying the bit positions in the CSR to be cleared. If the CSR bit is writable, any high bit in rs1 will cause the corresponding bit in CSR to be cleared. Other bits in the CSR are not written explicitly.
For both CSRRS and CSRRC, if rs1=x0, then the instruction will not write to the CSR at all, and so shall not cause any of the side effects that might otherwise occur on a CSR write, nor raise illegal instruction exceptions on accesses to read-only CSRs. Both CSRRS and CSRRC always read the addressed CSR and cause any read side effects regardless of rs1 and rd fields. Note that if rs1 specifies a register holding a zero value other than x0, the instruction will still attempt to write the unmodified value back to the CSR and will cause any attendant side effects. A CSRRW with rs1=x0 will attempt to write zero to the destination CSR.
For CSRRS and CSRRC, if rs1=x0, the instruction will not write to the CSR at all, thus not causing any side effects that might occur with a CSR write, nor raising an illegal instruction exception when accessing a read-only CSR. Regardless of the rs1 and rd fields, CSRRS and CSRRC always read the addressed CSR with any read side effects. Note that if the register specified by rs1 other than x0 has a value of zero, the instruction will still attempt to write the unmodified value back to the CSR, causing any corresponding side effects. A CSRRW with rs1=x0 will attempt to write a value of zero to the target CSR.
The CSRRWI, CSRRSI, and CSRRCI variants are similar to CSRRW, CSRRS, and CSRRC respectively, except they update the CSR using an XLEN-bit value obtained by zero-extending a 5-bit unsigned immediate (uimm[4:0]) field encoded in the rs1 field instead of a value from an integer register. For CSRRSI and CSRRCI, if the uimm[4:0] field is zero, then these instructions will not write to the CSR, and shall not cause any of the side effects that might otherwise occur on a CSR write, nor raise illegal instruction exceptions on accesses to read-only CSRs. For CSRRWI, if rd=x0, then the instruction shall not read the CSR and shall not cause any of the side effects that might occur on a CSR read. Both CSRRSI and CSRRCI will always read the CSR and cause any read side effects regardless of rd and rs1 fields.
The CSRRWI, CSRRSI, and CSRRCI variants are similar to CSRRW, CSRRS, and CSRRC, respectively, but they update the CSR using the The XLEN bit value of , not the value in an integer register. For CSRRSI and CSRRCI, if the uimm[4:0] field is zero, these instructions will not write to the CSR, will not cause any side effects that may occur on a CSR write, and will not raise an illegal access to a read-only CSR Command exception. For CSRRWI, if rd=x0, the instruction does not read the CSR, nor does it cause any side effects that may occur when reading the CSR. CSRRSI and CSRRCI will always read the CSR and cause any read side effects, regardless of the rd and rs1 fields.
Conditions determining whether a CSR instruction reads or writes the specified CSR: Table summarizes
the behavior of the CSR instructions with respect to whether they read and/or write the CSR.
Behavior of the CSR instruction when reading and/or writing the CSR.
For any event or consequence that occurs due to a CSR having a particular value, if a write to the CSR gives it that value, the resulting event or consequence is said to be an indirect effect of the write. Indirect effects of a CSR write are not considered by the RISC-V ISA to be
side effects of that write. Called the indirect effect of writing. The RISC-V ISA does not treat the indirect effects of CSR writes as side effects of the write.
Note:
An example of side effects for CSR accesses would be if reading from a specific CSR causes a light bulb to turn on, while writing an odd value to the same CSR causes the light to turn off. Assume writing an even value has no effect. In this case, both the read and write have side effects controlling whether the bulb is lit, as this condition is not determined solely from the CSR value. (Note that after writing an odd value to the CSR to turn off the light, then reading to turn the light on, writing again the same odd value causes the light to turn off again. Hence, on the last write, it is not a change in the CSR value that turns off the
light.)
An example of a side effect of accessing a CSR is if a read from a particular CSR causes a light bulb to turn on, while writing an odd value to the same CSR causes the light bulb to turn off. Assume writing an even value has no effect. In this case, both reading and writing have the side effect of controlling whether the light bulb is on or not, since this condition is not entirely determined by the CSR value. (Please note that after writing an odd value to the CSR to turn off the light, and then reading an odd value to turn on the light, writing the same odd value again will cause the light to turn off again. Therefore, it is not the change of the CSR value at the time of the last write On
the other hand, if a bulb is rigged to light whenever the value of a particular CSR is odd, then turning the light on and off is not considered a side effect of writing to the CSR but merely an indirect effect of such writes.
On the other hand, if a light bulb is installed when the value of a certain CSR is odd, the on and off of the light is not considered a side effect of the write to the CSR, but only an indirect effect of the write to the CSR. More concretely
, the RISC-V privileged architecture defined in Volume II specifies that certain combinations of CSR values cause a trap to occur. When an explicit write to a CSR creates the conditions that trigger the trap, the trap is not considered a side effect of the write but only an indirect effect.
More specifically, the RISC-V privileged architecture defined in Volume II specifies that certain combinations of CSR values cause traps to occur. When an explicit write to a CSR produces a condition that triggers a trap, the trap is not considered a side effect of the write, but an indirect effect.
Standard CSRs do not have any side effects on reads. Standard CSRs may have side effects on writes. Custom extensions might add CSRs for which accesses have side effects on either reads or writes
. Standard CSRs may have side effects on writes. Custom extensions may add CSRs that have side effects on reads or writes.
Some CSRs, such as the instructions-retired counter, instret, may be modified as side effects of instruction execution. In these cases, if a CSR access instruction reads a CSR, it reads the value prior to the execution of the instruction. If a CSR access instruction writes such a CSR, the write is done instead of the increment. In particular, a value written to instret by one instruction will be the value read by the following instruction. Certain CSRs (such as instruction retirement counter instret)
may Modified as a side effect of instruction execution. In this case, if a CSR access instruction reads the CSR, the value is read before the instruction executes. If a CSR access instruction writes to such a CSR, it is written rather than incremented. In particular, the value written to instret by one instruction becomes the value read by the next instruction.
The assembler pseudoinstruction to read a CSR, CSRR rd, csr, is encoded as CSRRS rd, csr, x0. The assembler pseudoinstruction to write a CSR, CSRW csr, rs1, is encoded as CSRRW x0, csr, rs1, while CSRWI csr, uimm, is encoded as CSRRWI x0, csr, uimm.
The assembly directive CSRR rd, csr that reads CSR is encoded as CSRRS rd, csr, x0. The assembler directive CSRW csr, rs1 that writes to the CSR is coded as CSRRW x0, csr, rs1, and the CSRWI csr, uimm is coded as CSRRWI x0, csr, uimm. Further assembler pseudoinstructions
are defined to set and clear bits in the CSR when the old value is not required: CSRS/CSRC csr, rs1; CSRSI/CSRCI csr, uimm.
Set and clear bits in the CSR at old values: CSRS/CSRC csr, rs1; CSRSI/CSRCI csr, uimm.
2 CSR Access Ordering
Each RISC-V hart normally observes its own CSR accesses, including its implicit CSR accesses, as performed in program order. In particular, unless specified otherwise, a CSR access is performed after the execution of any prior instructions in program order whose behavior modifies or is modified by the CSR state and before the execution of any subsequent instructions in program order whose behavior modifies or is modified by the CSR state. Furthermore, an explicit CSR read returns the CSR state before the execution of the instruction, while an explicit CSR write suppresses and overrides any implicit writes or modifications to the same CSR by the same instruction.
Each RISC-V hart normally performs its own CSR accesses, including implicit CSR accesses, in program order. Specifically, unless otherwise specified, a CSR access follows the execution of any preceding instruction in program order whose behavior is modified or modified by the CSR state, and before the execution of any subsequent instruction in program order whose behavior is modified or modified by the CSR state ongoing. Additionally, an explicit CSR read returns the status of the CSR prior to instruction execution, while an explicit CSR write suppresses and overwrites any implicit write or modification of the same CSR by the same instruction.
Likewise, any side effects from an explicit CSR access are normally observed to occur synchronously in program order. Unless specified otherwise, the full consequences of any such side effects are observable by the very next instruction, and no consequences may be observed out-of- order by preceding instructions. (Note the distinction made earlier between side effects and indirect effects of CSR writes.)
Likewise, any side effects from explicit CSR accesses will generally occur synchronously in program order. Unless otherwise specified, the full consequences of any such side effects are observable in the next instruction, whereas no non-sequential consequences are observable for preceding instructions. (Note the distinction made earlier between side effects and indirect effects of CSR writing).
For the RVWMO memory consistency model (Chapter 17), CSR accesses are weakly ordered by default, so other harts or devices may observe CSR accesses in an order different from program order. In addition, CSR accesses are not ordered with respect to explicit memory accesses, unless a CSR access modifies the execution behavior of the instruction that performs the explicit memory access or unless a CSR access and an explicit memory access are ordered by either the syntactic dependencies defined by the memory model or the ordering requirements defined by the Memory-Ordering PMAs section in Volume II of this manual. To enforce ordering in all other cases, software should execute a FENCE instruction between the relevant accesses. For the purposes of the FENCE instruction, CSR read accesses are classified as device input (I), and CSR write accesses are classified as device output (O).
For the RVWMO memory consistency model (Chapter 17), CSR accesses are weakly ordered by default, so other Harts or devices may observe CSR accesses in a different order than program order. Furthermore, unless the CSR access modifies the execution behavior of the instruction that performs the explicit memory access, or the CSR access and the explicit memory access require ordering according to the syntactic dependencies defined by the memory model or the ordering defined in the Memory Ordering PMA section of Volume II of this manual, Otherwise CSR accesses are not ordered relative to explicit memory accesses. To perform sequencing in all other cases, software should execute a FENCE instruction between related accesses. For the purposes of the FENCE instruction, CSR read accesses are classified as device inputs (I) and CSR write accesses are classified as device outputs (O).
Note:
Informally, the CSR space acts as a weakly ordered memory-mapped I/O region, as defined by the Memory-Ordering PMAs section in Volume II of this manual. As a result, the order of CSR accesses with respect to all other accesses is constrained by the same mechanisms that constrain the order of memory-mapped I/O accesses to such a region.
As defined in the "Memory Ordering PMA" section of Volume II of this manual, the CSR space is a weakly ordered memory-mapped I/O area. Therefore, the ordering of CSR accesses relative to all other accesses is subject to the same mechanism that restricts the ordering of memory-mapped I/O accesses.
These CSR-ordering constraints are imposed to support ordering main memory and memory-mapped I/O accesses with respect to CSR accesses that are visible to, or affected by, devices or other harts. Examples include the time, cycle, and mcycle CSRs, in addition to CSRs that reflect pending interrupts, like mip and sip. Note that implicit reads of such CSRs (eg, taking an interrupt because of a change in mip) are also ordered as device input. These CSR ordering constraints are implemented to
support Sorts main memory and memory-mapped I/O accesses to be consistent with CSR accesses that are visible to or affected by the device or other hardware. Examples include time, cycle, and mcycle CSRs, and CSRs that reflect pending interrupts, such as mip and sip. Note that implicit reads of such CSRs (for example, interrupts due to mip changes) are also ordered as device inputs.
Most CSRs (including, eg, the fcsr) are not visible to other harts; their accesses can be freely reordered in the global memory order with respect to FENCE instructions without violating this specification. Most CSRs (including fcsr, etc.) are not visible to other
harts are invisible; their accesses can be freely reordered in global memory according to the FENCE instruction without violating this specification.
The hardware platform may define that accesses to certain CSRs are strongly ordered, as defined by the Memory-Ordering PMAs section in Volume II of this manual. Accesses to strongly ordered CSRs have stronger ordering constraints with respect to accesses to both weakly ordered CSRs s and accesses to memory-mapped I/O regions.
According to the definition in the "Memory Ordering PMA" section of Volume II of this manual, the hardware platform can define access to certain CSRs as strong ordering. Accesses to strongly-ordered CSRs have stronger ordering constraints than accesses to weakly-ordered CSRs and accesses to memory-mapped I/O regions.
3 CSR instruction set type
