diff options
author | elisa <elisa@riscv.org> | 2021-09-28 09:26:30 -0700 |
---|---|---|
committer | elisa <elisa@riscv.org> | 2021-09-28 09:26:30 -0700 |
commit | c755f05b62e435e43de88abf4b68b1575e239957 (patch) | |
tree | 89f7f4cbe788006f4a9cb2ef40a8e5b06b9cde47 | |
parent | 937f16832c71e9b1c794fe02a11c7ebb7837ead8 (diff) | |
download | riscv-isa-manual-c755f05b62e435e43de88abf4b68b1575e239957.zip riscv-isa-manual-c755f05b62e435e43de88abf4b68b1575e239957.tar.gz riscv-isa-manual-c755f05b62e435e43de88abf4b68b1575e239957.tar.bz2 |
some table fixes and additions of missing formatting
-rw-r--r-- | src/c-st-ext.adoc | 120 | ||||
-rw-r--r-- | src/d-st-ext.adoc | 2 | ||||
-rw-r--r-- | src/f-st-ext.adoc | 11 | ||||
-rw-r--r-- | src/images/wavedrom/quad-ls.adoc | 1 | ||||
-rw-r--r-- | src/intro.adoc | 3 | ||||
-rw-r--r-- | src/mm-eplan.adoc | 21 | ||||
-rw-r--r-- | src/naming.adoc | 127 | ||||
-rw-r--r-- | src/q-st-ext.adoc | 3 | ||||
-rw-r--r-- | src/riscv-isa-unpr-conv-review.pdf | bin | 6089231 -> 5995674 bytes | |||
-rw-r--r-- | src/rv32.adoc | 7 | ||||
-rw-r--r-- | src/rv64.adoc | 2 | ||||
-rw-r--r-- | src/rvwmo.adoc | 196 | ||||
-rw-r--r-- | src/zicsr.adoc | 2 |
13 files changed, 266 insertions, 229 deletions
diff --git a/src/c-st-ext.adoc b/src/c-st-ext.adoc index 6675a5a..13c2388 100644 --- a/src/c-st-ext.adoc +++ b/src/c-st-ext.adoc @@ -15,14 +15,14 @@ reduction. RVC uses a simple compression scheme that offers shorter 16-bit versions of common 32-bit RISC-V instructions when: -the immediate or address offset is small, or +* the immediate or address offset is small, or -one of the registers is the zero register (`x0`), the ABI link register +* one of the registers is the zero register (`x0`), the ABI link register (`x1`), or the ABI stack pointer (`x2`), or -the destination register and the first source register are identical, or +* the destination register and the first source register are identical, or -the registers used are the 8 most popular ones. +* the registers used are the 8 most popular ones. The C extension is compatible with all other standard instruction extensions. The C extension allows 16-bit instructions to be freely @@ -31,8 +31,11 @@ on any 16-bit boundary, i.e., IALIGN=16. With the addition of the C extension, no instructions can raise instruction-address-misaligned exceptions. +[NOTE] +==== Removing the 32-bit alignment constraint on the original 32-bit instructions allows significantly greater code density. +==== The compressed instruction encodings are mostly common across RV32C, RV64C, and RV128C, but as shown in @@ -51,6 +54,8 @@ and/or D) is also implemented. In addition, RV32C includes a compressed jump and link instruction to compress short-range subroutine calls, where the same opcode is used to compress ADDIW for RV64C and RV128C. +[TIP] +==== Double-precision loads and stores are a significant fraction of static and dynamic instructions, hence the motivation to include them in the RV32C and RV64C encoding. @@ -73,29 +78,34 @@ complexity is small even for designs that support multiple base ISAs. The compressed floating-point load and store variants use the same instruction format with the same register specifiers as the wider integer loads and stores. +==== RVC was designed under the constraint that each RVC instruction expands into a single 32-bit instruction in either the base ISA (RV32I/E, RV64I, or RV128I) or the F and D standard extensions where present. Adopting this constraint has two main benefits: -Hardware designs can simply expand RVC instructions during decode, +* Hardware designs can simply expand RVC instructions during decode, simplifying verification and minimizing modifications to existing microarchitectures. - -Compilers can be unaware of the RVC extension and leave code compression +* Compilers can be unaware of the RVC extension and leave code compression to the assembler and linker, although a compression-aware compiler will generally be able to produce better results. +[TIP] +==== We felt the multiple complexity reductions of a simple one-one mapping between C and base IFD instructions far outweighed the potential gains of a slightly denser encoding that added additional instructions only supported in the C extension, or that allowed encoding of multiple IFD instructions in one C instruction. +==== It is important to note that the C extension is not designed to be a stand-alone ISA, and is meant to be used alongside a base ISA. +[TIP] +==== Variable-length instruction sets have long been used to improve code density. For example, the IBM Stretch cite:[stretch], developed in the late 1950s, had an ISA with 32-bit and 64-bit instructions, where some of the 32-bit @@ -157,7 +167,8 @@ embedded applications _and_ to improve performance and energy-efficiency for all applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same -performance impact as doubling the instruction cache size . +performance impact as doubling the instruction cache size. +==== === Compressed Instruction Formats (((compressed, formats))) @@ -173,11 +184,14 @@ so prevalent, and that they use the CI and CSS formats to allow access to all 32 data registers. CIW supplies an 8-bit immediate for the ADDI4SPN instruction. +[NOTE] +==== The RISC-V ABI was changed to make the frequently used registers map to registers `x8`–`x15`. This simplifies the decompression decoder by having a contiguous naturally aligned set of register numbers, and is also compatible with the RV32E base ISA, which only has 16 integer registers. +==== (((compressed, loads and stores))) Compressed register-based floating-point loads and stores also use the @@ -185,9 +199,12 @@ CL and CS formats respectively, with the eight registers mapping to `f8` to `f15`. (((calling convention, standard))) +[NOTE] +==== The standard RISC-V calling convention maps the most frequently used floating-point registers to registers `f8` to `f15`, which allows the same register decompression decoding as for integer register numbers. +==== (((register source specifiers, c-ext))) The formats were designed to keep bits for the two register source @@ -198,19 +215,22 @@ encoding. Where immediates are sign-extended, the sign-extension is always from bit 12. Immediate fields have been scrambled, as in the base specification, to reduce the number of immediate muxes required. +[NOTE] +==== The immediate fields are scrambled in the instruction formats instead of in sequential order so that as many bits as possible are in the same position in every instruction, thereby simplifying implementations. +==== For many RVC instructions, zero-valued immediates are disallowed and `x0` is not a valid 5-bit register specifier. These restrictions free up encoding space for other instructions requiring fewer operand bits. -include::images/wavedrom/cr-register.adoc[] -[cr-register] -.Compressed 16-bit RVC instruction formats -image::image_placeholder.png[] -(((compressed, 16-bit))) +//include::images/wavedrom/cr-register.adoc[] +//[cr-register] +//.Compressed 16-bit RVC instruction formats +//image::image_placeholder.png[] +//(((compressed, 16-bit))) [[rvc-form]] .Compressed 16-bit RVC instruction formats. @@ -271,7 +291,6 @@ registers. ==== Stack-Pointer-Based Loads and Stores -. include::images/wavedrom/c-sp-load-store.adoc[] [c-sp-load-store] .Stack-Pointer-Based Loads and Stores @@ -345,6 +364,8 @@ to memory. It computes an effective address by adding the _zero_-extended offset, scaled by 8, to the stack pointer, `x2`. It expands to `fsd rs2, offset(x2)`. +[NOTE] +==== Register save/restore code at function entry/exit represents a significant portion of static code size. The stack-pointer-based compressed loads and stores in RVC are effective at reducing the @@ -381,6 +402,7 @@ While reasonable architects might come to different conclusions, we decided to omit load and store multiple and instead use the software-only approach of calling save/restore millicode routines to attain the greatest code size reduction. +==== ==== Register-Based Loads and Stores @@ -520,10 +542,13 @@ latexmath:[$\textit{rs1}{\neq}\texttt{x0}$]; the code point with latexmath:[$\textit{rs1}{=}\texttt{x0}$] corresponds to the C.EBREAK instruction. +[TIP] +==== Strictly speaking, C.JALR does not expand exactly to a base RVI instruction as the value added to the PC to form the link address is 2 rather than 4 as in the base ISA, but supporting both offsets of 2 and 4 bytes is only a very minor change to the base microarchitecture. +==== S@S@S@T@Y + & & & & + @@ -616,8 +641,11 @@ adjust the stack pointer in procedure prologues and epilogues. It expands into `addi x2, x2, nzimm`. C.ADDI16SP is only valid when _nzimm_latexmath:[$\neq$]0; the code point with _nzimm_=0 is reserved. +[NOTE] +==== In the standard RISC-V calling convention, the stack pointer `sp` is always 16-byte aligned. +==== @S@K@S@Y + & & & + @@ -676,6 +704,8 @@ amount must be non-zero; the code points with _shamt_=0 are HINTs. C.SRAI is defined analogously to C.SRLI, but instead performs an arithmetic right shift. C.SRAI expands to `srai rd, rd, shamt`. +[NOTE] +==== Left shifts are usually more frequent than right shifts, as left shifts are frequently used to scale address values. Right shifts have therefore been granted less encoding space and are placed in an encoding quadrant @@ -686,6 +716,7 @@ amounts of 96–127 will be more useful than 64–95, to allow extraction of tags located in the high portions of 128-bit address pointers. We note that RV128C will not be frozen at the same point as RV32C and RV64C, to allow evaluation of typical usage of 128-bit address-space codes. +==== S@W@Y@S@T@Y + & & & & & + @@ -717,11 +748,14 @@ instruction. The code points with latexmath:[$\textit{rs2}{\neq}\texttt{x0}$] and latexmath:[$\textit{rd}{=}\texttt{x0}$] are HINTs. +[NOTE] +==== C.MV expands to a different instruction than the canonical MV pseudoinstruction, which instead uses ADDI. Implementations that handle MV specially, e.g. using register-renaming hardware, may find it more convenient to expand C.MV to MV instead of ADD, at slight additional hardware cost. +==== C.ADD adds the values in registers _rd_ and _rs2_ and writes the result to register _rd_. C.ADD expands into `add rd, rd, rs2`. C.ADD is only @@ -776,10 +810,13 @@ _rd latexmath:[$'$]_, then sign-extends the lower 32 bits of the difference before writing the result to register _rd latexmath:[$'$]_. C.SUBW expands into `subw rd', rd', rs2'`. +[NOTE] +==== This group of six instructions do not provide large savings individually, but do not occupy much encoding space and are straightforward to implement, and as a group provide a worthwhile improvement in static and dynamic compression. +==== ==== Defined Illegal Instruction @@ -792,6 +829,8 @@ SW@T@T@Y + A 16-bit instruction with all bits zero is permanently reserved as an illegal instruction. +[NOTE] +==== We reserve all-zero instructions to be illegal instructions to help trap attempts to execute zero-ed or non-existent portions of the memory space. The all-zero value should not be redefined in any non-standard @@ -799,6 +838,7 @@ extension. Similarly, we reserve instructions with all bits set to 1 (corresponding to very long instructions in the RISC-V variable-length encoding scheme) as illegal to capture another common value seen in non-existent memory regions. +==== ==== NOP Instruction @@ -833,9 +873,12 @@ I instructions permitted inside constrained LR/SC sequences, as described in <<lrscseq>>, are also permitted inside constrained LR/SC sequences. +[NOTE] +==== The implication is that any implementation that claims to support both the A and C extensions must ensure that LR/SC sequences containing valid C instructions will eventually complete. +==== [[rvc-hints]] === HINT Instructions @@ -942,46 +985,45 @@ RVC instructions. //[cols="<,<,<,<,<,<,<,<,<,<,<,<,<,<,<,<,<,<",] |=== -|000| |0 | | | | | | | |0 | | |00 | |_Illegal instruction_ +|000|0 | | | | | | |0 | | |00 |_Illegal instruction_ -|000| -|nzuimm[5:4latexmath:[$\vert$]9:6latexmath:[$\vert$]2latexmath:[$\vert$]3] -| | | | | | | |rd latexmath:[$'$] | | |00 | |C.ADDI4SPN _(RES, +|000|nzuimm[5:4latexmath:[$\vert$]9:6latexmath:[$\vert$]2latexmath:[$\vert$]3] +| | | | | | |rd latexmath:[$'$] | | |00 |C.ADDI4SPN _(RES, nzuimm=0)_ -|001| |uimm[5:3] | | |rs1 latexmath:[$'$] | | |uimm[7:6] | -|rd latexmath:[$'$] | | |00 | |C.FLD _(RV32/64)_ +|001|uimm[5:3] | |rs1 latexmath:[$'$] | | |uimm[7:6] | +|rd latexmath:[$'$] | |00 |C.FLD _(RV32/64)_ -|001| |uimm[5:4latexmath:[$\vert$]8] | | |rs1 latexmath:[$'$] | | -|uimm[7:6] | |rd latexmath:[$'$] | | |00 | |C.LQ _(RV128)_ +|001|uimm[5:4latexmath:[$\vert$]8] | |rs1 latexmath:[$'$] | | +|uimm[7:6] | |rd latexmath:[$'$] | | |00 |C.LQ _(RV128)_ -|010| |uimm[5:3] | | |rs1 latexmath:[$'$] | | -|uimm[2latexmath:[$\vert$]6] | |rd latexmath:[$'$] | | |00 | |C.LW +|010|uimm[5:3] | |rs1 latexmath:[$'$] | | +|uimm[2latexmath:[$\vert$]6] | |rd latexmath:[$'$] | | |00 |C.LW -|011| |uimm[5:3] | | |rs1 latexmath:[$'$] | | -|uimm[2latexmath:[$\vert$]6] | |rd latexmath:[$'$] | | |00 | |C.FLW +|011|uimm[5:3] | |rs1 latexmath:[$'$] | | +|uimm[2latexmath:[$\vert$]6] | |rd latexmath:[$'$] | | |00 |C.FLW _(RV32)_ -|011| |uimm[5:3] | | |rs1 latexmath:[$'$] | | |uimm[7:6] | -|rd latexmath:[$'$] | | |00 | |C.LD _(RV64/128)_ +|011|uimm[5:3] | |rs1 latexmath:[$'$] | | |uimm[7:6] | +|rd latexmath:[$'$] | | |00 |C.LD _(RV64/128)_ -|100| |— | | | | | | | | | | |00 | |_Reserved_ +|100|— | | | | | | | | | |00 |_Reserved_ -|101| |uimm[5:3] | | |rs1 latexmath:[$'$] | | |uimm[7:6] | -|rs2 latexmath:[$'$] | | |00 | |C.FSD _(RV32/64)_ +|101|uimm[5:3] | |rs1 latexmath:[$'$] | | |uimm[7:6] | +|rs2 latexmath:[$'$] | | |00 |C.FSD _(RV32/64)_ -|101 | | |uimm[5:4latexmath:[$\vert$]8] | | |rs1 latexmath:[$'$] | | -|uimm[7:6] | |rs2 latexmath:[$'$] | | |00 | |C.SQ _(RV128)_ +|101 |uimm[5:4latexmath:[$\vert$]8] | |rs1 latexmath:[$'$] | | +|uimm[7:6] | |rs2 latexmath:[$'$] | | |00 |C.SQ _(RV128)_ -|110| |uimm[5:3] | | |rs1 latexmath:[$'$] | | -|uimm[2latexmath:[$\vert$]6] | |rs2 latexmath:[$'$] | | |00 | |C.SW +|110|uimm[5:3] | |rs1 latexmath:[$'$] | | +|uimm[2latexmath:[$\vert$]6] | |rs2 latexmath:[$'$] | | |00 |C.SW -|111| |uimm[5:3] | | |rs1 latexmath:[$'$] | | -|uimm[2latexmath:[$\vert$]6] | |rs2 latexmath:[$'$] | | |00 | |C.FSW +|111|uimm[5:3] | |rs1 latexmath:[$'$] | | +|uimm[2latexmath:[$\vert$]6] | |rs2 latexmath:[$'$] | | |00 |C.FSW _(RV32)_ -|111| |uimm[5:3] | | |rs1 latexmath:[$'$] | | |uimm[7:6] | -|rs2 latexmath:[$'$] | | |00 | |C.SD _(RV64/128)_ +|111|uimm[5:3] | |rs1 latexmath:[$'$] | | |uimm[7:6] | +|rs2 latexmath:[$'$] | | |00 |C.SD _(RV64/128)_ |=== diff --git a/src/d-st-ext.adoc b/src/d-st-ext.adoc index 1b8768d..815f904 100644 --- a/src/d-st-ext.adoc +++ b/src/d-st-ext.adoc @@ -1,4 +1,4 @@ -== ``D`` Standard Extension for Double-Precision Floating-Point, Version 2.2 +== D Standard Extension for Double-Precision Floating-Point, Version 2.2 This chapter describes the standard double-precision floating-point instruction-set extension, which is named `D` and adds diff --git a/src/f-st-ext.adoc b/src/f-st-ext.adoc index 90239be..7b3d0e9 100644 --- a/src/f-st-ext.adoc +++ b/src/f-st-ext.adoc @@ -1,5 +1,5 @@ [[single-float]] -== `F` Standard Extension for Single-Precision Floating-Point, Version 2.2 +== F Standard Extension for Single-Precision Floating-Point, Version 2.2 This chapter describes the standard instruction-set extension for single-precision floating-point, which is named `F` and adds @@ -46,7 +46,6 @@ control and status register (CSR). It is a 32-bit read/write register that selects the dynamic rounding mode for floating-point arithmetic operations and holds the accrued exception flags, as shown in <<fcsr>>. - include::images/wavedrom/float-csr.adoc[] [[fcsr]] .Floating-point control and status register @@ -69,7 +68,6 @@ then writing a new value obtained from the three least-significant bits of integer register _rs1_ into `frm`. FRFLAGS and FSFLAGS are defined analogously for the Accrued Exception Flags field `fflags`. - Bits 31–8 of the `fcsr` are reserved for other standard extensions. If these extensions are not present, implementations shall ignore writes to these bits and supply a zero value when read. Standard software should @@ -104,7 +102,6 @@ particular, with regard to decoding legal vs. reserved encodings). | | |In Rounding Mode register, _reserved_. |=== - [NOTE] ==== The C99 language standard effectively mandates the provision of a @@ -122,7 +119,6 @@ reserved encoding, so implementations compatible with the ratified spec are compatible with the weakened spec. ==== - The accrued exception flags indicate the exception conditions that have arisen on any floating-point arithmetic instruction since the field was last reset by software, as shown in <<bitdef>>. The base @@ -152,14 +148,14 @@ ultimately chose to omit these instructions to keep the ISA simple. ==== === NaN Generation and Propagation -(((NaN, generation))) -(((NaN, propagation))) Except when otherwise stated, if the result of a floating-point operation is NaN, it is the canonical NaN. The canonical NaN has a positive sign and all significand bits clear except the MSB, a.k.a. the quiet bit. For single-precision floating-point, this corresponds to the pattern `0x7fc00000`. +(((NaN, generation))) +(((NaN, propagation))) [TIP] ==== @@ -460,7 +456,6 @@ include::images/wavedrom/spfloat-mv.adoc[] .SP floating point move image::image_placeholder.png[] - [TIP] ==== The base floating-point ISA was defined so as to allow implementations diff --git a/src/images/wavedrom/quad-ls.adoc b/src/images/wavedrom/quad-ls.adoc index 2cef49c..7cb2799 100644 --- a/src/images/wavedrom/quad-ls.adoc +++ b/src/images/wavedrom/quad-ls.adoc @@ -23,3 +23,4 @@ ]} .... + diff --git a/src/intro.adoc b/src/intro.adoc index d57a12a..f455e54 100644 --- a/src/intro.adoc +++ b/src/intro.adoc @@ -729,3 +729,6 @@ Like the base architecture, extensions should fully describe allowable behavior and values and use the term _unspecified_ for cases that are intentionally unconstrained. These cases may be constrained or defined by other extensions, platform standards, or implementations. + + +Susan Anstey diff --git a/src/mm-eplan.adoc b/src/mm-eplan.adoc index 2b282e5..e2d8aa8 100644 --- a/src/mm-eplan.adoc +++ b/src/mm-eplan.adoc @@ -207,8 +207,6 @@ is determined by the load value axiom, not just strictly by determining the most recent store to the same address in the global memory order, as described below. - - [[loadvalueaxiom]] ==== Load value axiom @@ -250,7 +248,6 @@ _A store buffer forwarding litmus test (outcome permitted)_ |Outcome: `a0=1`, `a1=0`, `a2=1`, `a3=0` | | | |=== - Consider the litmus test of <<storebuffer>>. When running this program on an implementation with store buffers, it is possible to arrive at the final outcome `a0=1`, `a1=0`, `a2=1`, `a3=0` as follows: @@ -491,7 +488,6 @@ graphviz::images/graphviz/MMM.txt[] [[loadvalueaxiom]] .A sample litmus test and one forbidden execution (a0=1) - [cols="^,<,^,<",options="header",] |=== |Hart 0 | |Hart 1 | @@ -505,7 +501,6 @@ graphviz::images/graphviz/MMM.txt[] |Outcome: `a0=1`, `a1=2`, `a2=0` | | | |=== - Consider the litmus test of <<frirfi>>, which is one particular instance of the more general `fri-rfi` pattern. The term `fri-rfi` @@ -539,10 +534,6 @@ order without violating CoRR. Note that this is not the same as saying that the two loads return the same value, since two different stores may write the same value. -m.4@m.6 - -` ` - [cols="^,<,^,<",options="header",] |=== |Hart 0 | |Hart 1 | @@ -557,8 +548,6 @@ m.4@m.6 |Outcome: `a0=1`, `a1=v`, `a2=v`, `a3=0` | | | |=== -& - Consider the litmus test of <<litmus-rsw>>. The outcome `a0=1`, `a1=v`, `a2=v`, `a3=0` (where latexmath:[$v$] is some value written by another hart) can be observed by allowing (g) and @@ -874,8 +863,6 @@ m.4m0.05m.4 |Outcome: `a0=0`, `a3=0` | | | |=== -& & - In addition, the choice to respect dependencies originating at store-conditional instructions ensures that certain out-of-thin-air-like behaviors will be prevented. Consider @@ -923,8 +910,6 @@ m.4m.05m.4 |Outcome: `a0=1`, `a3=0` | | | |=== -& & - PPO rules ppo:addrdatarfi[[ppo:addrdatarfi]] and ppo:addrpo[[ppo:addrpo]] reflect behaviors of almost all real processor pipeline implementations. Rule ppo:addrdatarfi @@ -956,8 +941,6 @@ m.4m.05m.4 |Outcome: `a0=1`, `a3=0` | | | |=== -& & - If there were another store to the same address in between (e) and (f), as in <<litmus:addrdatarfi_no>>, then (f) would no longer be dependent on the data of (e) being resolved, @@ -987,8 +970,6 @@ m.4m.05m.4 ` ` |Outcome: `a0=1`, `a1=t` | | | |=== -& & - Consider <<addrpo>> (f) cannot be executed until the address for (e) is resolved, because it may turn out that the addresses match; i.e., that `a1=s0`. Therefore, (f) cannot be @@ -1263,7 +1244,6 @@ FENCE R,R similarly to how ISYNC maps for Power. |=== - With regards to <<linuxmappings>>, other constructs (such as spinlocks) should follow accordingly. Platforms or devices with non-coherent DMA may need additional synchronization (such @@ -1717,3 +1697,4 @@ enforce this ordering naturally. As such, even though this rule is not official, we recommend that implementers enforce it nevertheless in order to ensure forwards compatibility with the possible future addition of this rule to RVWMO. + diff --git a/src/naming.adoc b/src/naming.adoc index 2ac4465..bac0d25 100644 --- a/src/naming.adoc +++ b/src/naming.adoc @@ -24,23 +24,23 @@ ISA. Standard ISA extensions are given a name consisting of a single letter. For example, the first four standard extensions to the integer bases -are: `M` for integer multiplication and division, `A` for atomic -memory instructions, `F` for single-precision floating-point -instructions, and `D` for double-precision floating-point +are: "M" for integer multiplication and division, "A" for atomic +memory instructions, "F" for single-precision floating-point +instructions, and "D" for double-precision floating-point instructions. Any RISC-V instruction-set variant can be succinctly described by concatenating the base integer prefix with the names of the -included extensions, e.g., `RV64IMAFD`. +included extensions, e.g., "RV64IMAFD". -We have also defined an abbreviation `G to represent the -`IMAFDZicsr_Zifencei` base and extensions, as this is intended to +We have also defined an abbreviation "G" to represent the +"IMAFDZicsr_Zifencei" base and extensions, as this is intended to represent our standard general-purpose ISA. Standard extensions to the RISC-V ISA are given other reserved letters, -e.g., `Q` for quad-precision floating-point, or `C` for the 16-bit +e.g., "Q" for quad-precision floating-point, or "C" for the 16-bit compressed instruction format. Some ISA extensions depend on the presence of other extensions, e.g., -`D` depends on `F` and `F` depends on `Zicsr`. These dependences +"D" depends on "F" and "F" depends on "Zicsr". These dependences may be implicit in the ISA name: for example, RV32IF is equivalent to RV32IFZicsr, and RV32ID is equivalent to RV32IFD and RV32IFDZicsr. @@ -49,54 +49,54 @@ RV32IFZicsr, and RV32ID is equivalent to RV32IFD and RV32IFDZicsr. Recognizing that instruction sets may expand or alter over time, we encode extension version numbers following the extension name. Version numbers are divided into major and minor version numbers, separated by a -`p`. If the minor version is `0`, then `p0` can be omitted from +"p". If the minor version is "0", then "p0" can be omitted from the version string. Changes in major version numbers imply a loss of backwards compatibility, whereas changes in only the minor version number must be backwards-compatible. For example, the original 64-bit standard ISA defined in release 1.0 of this manual can be written in -full as `RV64I1p0M1p0A1p0F1p0D1p0`, more concisely as -`RV64I1M1A1F1D1`. +full as "RV64I1p0M1p0A1p0F1p0D1p0", more concisely as +"RV64I1M1A1F1D1". We introduced the version numbering scheme with the second release. Hence, we define the default version of a standard extension to be the -version present at that time, e.g., `RV32I` is equivalent to -`RV32I2`. +version present at that time, e.g., "RV32I" is equivalent to +"RV32I2". === Underscores -Underscores `\_` may be used to separate ISA extensions to improve -readability and to provide disambiguation, e.g., `RV32I2_M2_A2`. +Underscores "_" may be used to separate ISA extensions to improve +readability and to provide disambiguation, e.g., "RV32I2_M2_A2". -Because the `P` extension for Packed SIMD can be confused for the +Because the "P" extension for Packed SIMD can be confused for the decimal point in a version number, it must be preceded by an underscore -if it follows a number. For example, `rv32i2p2` means version 2.2 of -RV32I, whereas `rv32i2_p2` means version 2.0 of RV32I with version 2.0 +if it follows a number. For example, "rv32i2p2" means version 2.2 of +RV32I, whereas "rv32i2_p2" means version 2.0 of RV32I with version 2.0 of the P extension. === Additional Standard Extension Names -Standard extensions can also be named using a single `Z` followed by +Standard extensions can also be named using a single "Z" followed by an alphabetical name and an optional version number. For example, -`Zifencei` names the instruction-fetch fence extension described in -<<zifencei>>; `Zifencei2` and -`Zifencei2p0` name version 2.0 of same. +"Zifencei" names the instruction-fetch fence extension described in +<<zifencei>>; "Zifencei2" and +"Zifencei2p0" name version 2.0 of same. -The first letter following the `Z` conventionally indicates the most +The first letter following the "Z" conventionally indicates the most closely related alphabetical extension category, IMAFDQLCBKJTPV. For the -`Zam` extension for misaligned atomics, for example, the letter `a` -indicates the extension is related to the `A` standard extension. If -multiple `Z` extensions are named, they should be ordered first by +"Zam" extension for misaligned atomics, for example, the letter "a" +indicates the extension is related to the "A" standard extension. If +multiple "Z" extensions are named, they should be ordered first by category, then alphabetically within a category—for example, -`Zicsr_Zifencei_Zam`. +"Zicsr_Zifencei_Zam". -Extensions with the `Z` prefix must be separated from other +Extensions with the "Z" prefix must be separated from other multi-letter extensions by an underscore, e.g., -`RV32IMACZicsr_Zifencei`. +"RV32IMACZicsr_Zifencei". === Supervisor-level Instruction-Set Extensions Standard supervisor-level instruction-set extensions are defined in -Volume II, but are named using `S` as a prefix, followed by an +Volume II, but are named using "S" as a prefix, followed by an alphabetical name and an optional version number. Supervisor-level extensions must be separated from other multi-letter extensions by an underscore. @@ -108,8 +108,8 @@ listed, they should be ordered alphabetically. === Hypervisor-level Instruction-Set Extensions Standard hypervisor-level instruction-set extensions are named like -supervisor-level extensions, but beginning with the letter `H` instead -of the letter `S`. +supervisor-level extensions, but beginning with the letter "H" instead +of the letter "S". Standard hypervisor-level extensions should be listed after standard lesser-privileged extensions. If multiple hypervisor-level extensions @@ -118,7 +118,7 @@ are listed, they should be ordered alphabetically. === Machine-level Instruction-Set Extensions Standard machine-level instruction-set extensions are prefixed with the -three letters `Zxm`. +three letters "Zxm". Standard machine-level extensions should be listed after standard lesser-privileged extensions. If multiple machine-level extensions are @@ -126,15 +126,15 @@ listed, they should be ordered alphabetically. === Non-Standard Extension Names -Non-standard extensions are named using a single `X` followed by an +Non-standard extensions are named using a single "X" followed by an alphabetical name and an optional version number. For example, -`Xhwacha` names the Hwacha vector-fetch ISA extension; `Xhwacha2` -and `Xhwacha2p0` name version 2.0 of same. +"Xhwacha" names the Hwacha vector-fetch ISA extension; "Xhwacha2" +and "Xhwacha2p0" name version 2.0 of same. Non-standard extensions must be listed after all standard extensions. They must be separated from other multi-letter extensions by an underscore. For example, an ISA with non-standard extensions Argle and -Bargle may be named `RV64IZifencei_Xargle_Xbargle`. +Bargle may be named "RV64IZifencei_Xargle_Xbargle". If multiple non-standard extensions are listed, they should be ordered alphabetically. @@ -142,43 +142,72 @@ alphabetically. === Subset Naming Convention <<isanametable>> summarizes the standardized extension -names. + - -[[isanametable]] -.Standard ISA extension names. The table also defines the canonical +names. The table also defines the canonical order in which extension names must appear in the name string, with top-to-bottom in table indicating first-to-last in the name string, e.g., RV32IMACV is legal, whereas RV32IMAVC is not. + +[[isanametable]] +.Standard ISA extension names. [cols="<,^,^",options="header",] |=== |Subset |Name |Implies + |Base ISA | | + |Integer |I | + |Reduced Integer |E | -|Standard Unprivileged Extensions | | + +3+|*Standard Unprivileged Extensions* + |Integer Multiplication and Division |M | + |Atomics |A | + |Single-Precision Floating-Point |F |Zicsr + |Double-Precision Floating-Point |D |F + |General |G |IMADZifencei + |Quad-Precision Floating-Point |Q |D + |16-bit Compressed Instructions |C | + |Bit Manipulation |B | + |Cryptography Extensions |K | + |Dynamic Languages |J | + |Packed-SIMD Extensions |P | + |Vector Extensions |V | + |Control and Status Register Access |Zicsr | + |Instruction-Fetch Fence |Zifencei | + |Misaligned Atomics |Zam |A + |Total Store Ordering |Ztso | -|Standard Supervisor-Level Extensions | | -|Supervisor-level extension `def` |Sdef | + +3+|*Standard Supervisor-Level Extensions* + +|Supervisor-level extension "def" |Sdef | + |Standard Hypervisor-Level Extensions | | -|Hypervisor-level extension `ghi` |Hghi | -|Standard Machine-Level Extensions | | -|Machine-level extension `jkl` |Zxmjkl | -|Non-Standard Extensions | | -|Non-standard extension `mno` |Xmno | + +|Hypervisor-level extension "ghi" |Hghi | + +3+|*Standard Machine-Level Extensions* + +|Machine-level extension "jkl" |Zxmjkl | + +3+|*Non-Standard Extensions* + +|Non-standard extension "mno" |Xmno | |=== + diff --git a/src/q-st-ext.adoc b/src/q-st-ext.adoc index bdca0f0..344857d 100644 --- a/src/q-st-ext.adoc +++ b/src/q-st-ext.adoc @@ -1,4 +1,4 @@ -== `Q` Standard Extension for Quad-Precision Floating-Point, Version 2.2 +== Q Standard Extension for Quad-Precision Floating-Point, Version 2.2 This chapter describes the Q standard extension for 128-bit quad-precision binary floating-point instructions compliant with the @@ -125,4 +125,3 @@ include::images/wavedrom/quad-float-clssfy.adoc[] image::image_placeholder.png[] - diff --git a/src/riscv-isa-unpr-conv-review.pdf b/src/riscv-isa-unpr-conv-review.pdf Binary files differindex 4bcd2e8..0d03229 100644 --- a/src/riscv-isa-unpr-conv-review.pdf +++ b/src/riscv-isa-unpr-conv-review.pdf diff --git a/src/rv32.adoc b/src/rv32.adoc index b035fe3..4fcd166 100644 --- a/src/rv32.adoc +++ b/src/rv32.adoc @@ -193,7 +193,6 @@ include::images/wavedrom/immediate.adoc[] .Immediate variants for I, S, B, U, and J image::image_placeholder.png[] - Sign-extension is one of the most critical operations on immediates (particularly for XLEN latexmath:[$>$]32), and in RISC-V the sign bit for all immediates is always held in bit 31 of the instruction to allow @@ -278,7 +277,6 @@ include::images/wavedrom/int-comp-slli-srli-srai.adoc[] .Integer register-immediate, SLLI, SRLI, SRAI image::image_placeholder.png[] - Shifts by a constant are encoded as a specialization of the I-type format. The operand to be shifted is in _rs1_, and the shift amount is encoded in the lower 5 bits of the I-immediate field. The right shift @@ -287,13 +285,11 @@ shifted into the lower bits); SRLI is a logical right shift (zeros are shifted into the upper bits); and SRAI is an arithmetic right shift (the original sign bit is copied into the vacated upper bits). - include::images/wavedrom/int-comp-lui-aiupc.adoc[] [[int-comp-lui-aiupc]] .Integer register-immediate, U-immediate image::image_placeholder.png[] - LUI (load upper immediate) is used to build 32-bit constants and uses the U-type format. LUI places the 32-bit U-immediate value into the destination register _rd_, filling in the lowest 12 bits with zeros. @@ -918,7 +914,7 @@ hints, security tags, and instrumentation flags for simulation/emulation. ==== -// this table isn't quite right and needs to be fixed--some rows might not have landed properly. It needs to be checked cell-by cell. +// this table might still have some problems--some rows might not have landed properly. It needs to be checked cell-by cell. [[t-rv32i-hints]] .RV32I HINT instructions. @@ -986,3 +982,4 @@ simulation/emulation. |SLTU |_rd_=`x0` |latexmath:[$2^{10}$] |=== + diff --git a/src/rv64.adoc b/src/rv64.adoc index 6214b5f..0a82de3 100644 --- a/src/rv64.adoc +++ b/src/rv64.adoc @@ -67,7 +67,6 @@ copied into the vacated upper bits). (((RV64I, SRLIW))) (((RV64I, RV64I-only))) - SLLIW, SRLIW, and SRAIW are RV64I-only instructions that are analogously defined but operate on 32-bit values and sign-extend their 32-bit results to 64 bits. SLLIW, SRLIW, and SRAIW encodings with @@ -256,3 +255,4 @@ use_ |SLTU | |_rd_=`x0` |latexmath:[$2^{10}$] |=== + diff --git a/src/rvwmo.adoc b/src/rvwmo.adoc index e6bc412..76559c3 100644 --- a/src/rvwmo.adoc +++ b/src/rvwmo.adoc @@ -273,17 +273,17 @@ latexmath:[$a$] and latexmath:[$b$] both access regular main memory * Overlapping-Address Orderings: . latexmath:[$b$] is a store, and latexmath:[$a$] and latexmath:[$b$] access overlapping memory addresses -. [#ppo:rdw]#[ppo:rdw]# latexmath:[$a$] and latexmath:[$b$] are loads, +. latexmath:[$a$] and latexmath:[$b$] are loads, latexmath:[$x$] is a byte read by both latexmath:[$a$] and latexmath:[$b$], there is no store to latexmath:[$x$] between latexmath:[$a$] and latexmath:[$b$] in program order, and latexmath:[$a$] and latexmath:[$b$] return values for latexmath:[$x$] written by different memory operations -. {empty}[#ppo:amoforward]#[ppo:amoforward]# latexmath:[$a$] is +. latexmath:[$a$] is generated by an AMO or SC instruction, latexmath:[$b$] is a load, and latexmath:[$b$] returns a value written by latexmath:[$a$] * Explicit Synchronization -. {empty} There is a FENCE instruction that +. There is a FENCE instruction that orders latexmath:[$a$] before latexmath:[$b$] . latexmath:[$a$] has an acquire annotation @@ -293,19 +293,19 @@ RCsc annotations . {empty} latexmath:[$a$] is paired with latexmath:[$b$] * Syntactic Dependencies -. {empty} latexmath:[$b$] has a syntactic address +. latexmath:[$b$] has a syntactic address dependency on latexmath:[$a$] -. {empty} latexmath:[$b$] has a syntactic data +. latexmath:[$b$] has a syntactic data dependency on latexmath:[$a$] -. {empty} latexmath:[$b$] is a store, and +. latexmath:[$b$] is a store, and latexmath:[$b$] has a syntactic control dependency on latexmath:[$a$] * Pipeline Dependencies -. {empty} latexmath:[$b$] is a +. latexmath:[$b$] is a load, and there exists some store latexmath:[$m$] between latexmath:[$a$] and latexmath:[$b$] in program order such that latexmath:[$m$] has an address or data dependency on latexmath:[$a$], and latexmath:[$b$] returns a value written by latexmath:[$m$] -. {empty} latexmath:[$b$] is a store, and +. latexmath:[$b$] is a store, and there exists some instruction latexmath:[$m$] between latexmath:[$a$] and latexmath:[$b$] in program order such that latexmath:[$m$] has an address dependency on latexmath:[$a$] @@ -398,53 +398,52 @@ any source register to any destination register latexmath:[$^\ddagger$]The instruction carries dependencies from source register(s) to destination register(s) as specified -[cols="<,<,<,<,<",] +[cols="<,<,<,<",] |=== -|*RV32I Base Integer Instruction Set* | | | | -| |Source |Destination |Accumulating | -| |Registers |Registers |CSRs | -|LUI | |_rd_ | | -|AUIPC | |_rd_ | | -|JAL | |_rd_ | | -|JALRlatexmath:[$^\dagger$] |_rs1_ |_rd_ | | -|BEQ |_rs1_, _rs2_ | | | -|BNE |_rs1_, _rs2_ | | | -|BLT |_rs1_, _rs2_ | | | -|BGE |_rs1_, _rs2_ | | | -|BLTU |_rs1_, _rs2_ | | | -|BGEU |_rs1_, _rs2_ | | | -|LBlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | | -|LHlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | | -|LWlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | | -|LBUlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | | -|LHUlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | | -|SB |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] | | | -|SH |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] | | | -|SW |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] | | | -|ADDI |_rs1_ |_rd_ | | -|SLTI |_rs1_ |_rd_ | | -|SLTIU |_rs1_ |_rd_ | | -|XORI |_rs1_ |_rd_ | | -|ORI |_rs1_ |_rd_ | | -|ANDI |_rs1_ |_rd_ | | -|SLLI |_rs1_ |_rd_ | | -|SRLI |_rs1_ |_rd_ | | -|SRAI |_rs1_ |_rd_ | | -|ADD |_rs1_, _rs2_ |_rd_ | | -|SUB |_rs1_, _rs2_ |_rd_ | | -|SLL |_rs1_, _rs2_ |_rd_ | | -|SLT |_rs1_, _rs2_ |_rd_ | | -|SLTU |_rs1_, _rs2_ |_rd_ | | -|XOR |_rs1_, _rs2_ |_rd_ | | -|SRL |_rs1_, _rs2_ |_rd_ | | -|SRA |_rs1_, _rs2_ |_rd_ | | -|OR |_rs1_, _rs2_ |_rd_ | | -|AND |_rs1_, _rs2_ |_rd_ | | -|FENCE | | | | -|FENCE.I | | | | -|ECALL | | | | -|EBREAK | | | | -| | | | | +|*RV32I Base Integer Instruction Set* | | | +| |Source |Destination |Accumulating +| |Registers |Registers |CSRs +|LUI | |_rd_ | +|AUIPC | |_rd_ | +|JAL | |_rd_ | +|JALRlatexmath:[$^\dagger$] |_rs1_ |_rd_ | +|BEQ |_rs1_, _rs2_ | | +|BNE |_rs1_, _rs2_ | | +|BLT |_rs1_, _rs2_ | | +|BGE |_rs1_, _rs2_ | | +|BLTU |_rs1_, _rs2_ | | +|BGEU |_rs1_, _rs2_ | | +|LBlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | +|LHlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | +|LWlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | +|LBUlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | +|LHUlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | +|SB |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] | | +|SH |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] | | +|SW |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] | | +|ADDI |_rs1_ |_rd_ | +|SLTI |_rs1_ |_rd_ | +|SLTIU |_rs1_ |_rd_ | +|XORI |_rs1_ |_rd_ | +|ORI |_rs1_ |_rd_ | +|ANDI |_rs1_ |_rd_ | +|SLLI |_rs1_ |_rd_ | +|SRLI |_rs1_ |_rd_ | +|SRAI |_rs1_ |_rd_ | +|ADD |_rs1_, _rs2_ |_rd_ | +|SUB |_rs1_, _rs2_ |_rd_ | +|SLL |_rs1_, _rs2_ |_rd_ | +|SLT |_rs1_, _rs2_ |_rd_ | +|SLTU |_rs1_, _rs2_ |_rd_ | +|XOR |_rs1_, _rs2_ |_rd_ | +|SRL |_rs1_, _rs2_ |_rd_ | +|SRA |_rs1_, _rs2_ |_rd_ | +|OR |_rs1_, _rs2_ |_rd_ | +|AND |_rs1_, _rs2_ |_rd_ | +|FENCE | | | +|FENCE.I | | | +|ECALL | | | +|EBREAK | | | |=== [cols="<,<,<,<,<",] @@ -488,56 +487,53 @@ from _csr_ to _rd_ | | | | |latexmath:[$\ddagger$]carries a dependency from _csr_ to _rd_ | | | |=== -[cols="<,<,<,<,<",] +[cols="<,<,<,<",] |=== -|*RV64I Base Integer Instruction Set* | | | | -| |Source |Destination |Accumulating | -| |Registers |Registers |CSRs | -|LWUlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | | -|LDlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | | -|SD |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] | | | -|SLLI |_rs1_ |_rd_ | | -|SRLI |_rs1_ |_rd_ | | -|SRAI |_rs1_ |_rd_ | | -|ADDIW |_rs1_ |_rd_ | | -|SLLIW |_rs1_ |_rd_ | | -|SRLIW |_rs1_ |_rd_ | | -|SRAIW |_rs1_ |_rd_ | | -|ADDW |_rs1_, _rs2_ |_rd_ | | -|SUBW |_rs1_, _rs2_ |_rd_ | | -|SLLW |_rs1_, _rs2_ |_rd_ | | -|SRLW |_rs1_, _rs2_ |_rd_ | | -|SRAW |_rs1_, _rs2_ |_rd_ | | -| | | | | +|*RV64I Base Integer Instruction Set* | | | +| |Source |Destination |Accumulating +| |Registers |Registers |CSRs +|LWUlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | +|LDlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$] |_rd_ | +|SD |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] | | +|SLLI |_rs1_ |_rd_ | +|SRLI |_rs1_ |_rd_ | +|SRAI |_rs1_ |_rd_ | +|ADDIW |_rs1_ |_rd_ | +|SLLIW |_rs1_ |_rd_ | +|SRLIW |_rs1_ |_rd_ | +|SRAIW |_rs1_ |_rd_ | +|ADDW |_rs1_, _rs2_ |_rd_ | +|SUBW |_rs1_, _rs2_ |_rd_ | +|SLLW |_rs1_, _rs2_ |_rd_ | +|SRLW |_rs1_, _rs2_ |_rd_ | +|SRAW |_rs1_, _rs2_ |_rd_ | |=== -[cols="<,<,<,<,<",] +[cols="<,<,<,<",] |=== -|*RV32M Standard Extension* | | | | -| |Source |Destination |Accumulating | -| |Registers |Registers |CSRs | -|MUL |_rs1_, _rs2_ |_rd_ | | -|MULH |_rs1_, _rs2_ |_rd_ | | -|MULHSU |_rs1_, _rs2_ |_rd_ | | -|MULHU |_rs1_, _rs2_ |_rd_ | | -|DIV |_rs1_, _rs2_ |_rd_ | | -|DIVU |_rs1_, _rs2_ |_rd_ | | -|REM |_rs1_, _rs2_ |_rd_ | | -|REMU |_rs1_, _rs2_ |_rd_ | | -| | | | | +|*RV32M Standard Extension* | | | +| |Source |Destination |Accumulating +| |Registers |Registers |CSRs +|MUL |_rs1_, _rs2_ |_rd_ | +|MULH |_rs1_, _rs2_ |_rd_ | +|MULHSU |_rs1_, _rs2_ |_rd_ | +|MULHU |_rs1_, _rs2_ |_rd_ | +|DIV |_rs1_, _rs2_ |_rd_ | +|DIVU |_rs1_, _rs2_ |_rd_ | +|REM |_rs1_, _rs2_ |_rd_ | +|REMU |_rs1_, _rs2_ |_rd_ | |=== -[cols="<,<,<,<,<",] +[cols="<,<,<,<",] |=== -|*RV64M Standard Extension* | | | | -| |Source |Destination |Accumulating | -| |Registers |Registers |CSRs | -|MULW |_rs1_, _rs2_ |_rd_ | | -|DIVW |_rs1_, _rs2_ |_rd_ | | -|DIVUW |_rs1_, _rs2_ |_rd_ | | -|REMW |_rs1_, _rs2_ |_rd_ | | -|REMUW |_rs1_, _rs2_ |_rd_ | | -| | | | | +|*RV64M Standard Extension* | | | +| |Source |Destination |Accumulating +| |Registers |Registers |CSRs +|MULW |_rs1_, _rs2_ |_rd_ | +|DIVW |_rs1_, _rs2_ |_rd_ | +|DIVUW |_rs1_, _rs2_ |_rd_ | +|REMW |_rs1_, _rs2_ |_rd_ | +|REMUW |_rs1_, _rs2_ |_rd_ | |=== [cols="<,<,<,<,<",] @@ -581,7 +577,6 @@ _rs2_latexmath:[$^D$] |_rd_ | | |AMOMAXU.Wlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] |_rd_ | | -| | | | | |=== [cols="<,<,<,<,<",] @@ -625,7 +620,6 @@ _rs2_latexmath:[$^D$] |_rd_ | | |AMOMAXU.Dlatexmath:[$^\dagger$] |_rs1_latexmath:[$^A$], _rs2_latexmath:[$^D$] |_rd_ | | -| | | | | |=== [cols="<,<,<,<,<",] @@ -701,7 +695,6 @@ rm=111 |FMV.W.X |_rs1_ |_rd_ | | -| | | | | |=== [cols="<,<,<,<,<",] @@ -724,7 +717,6 @@ rm=111 |FCVT.S.LU |_rs1_, frmlatexmath:[$^*$] |_rd_ |NX |latexmath:[$^*$]if rm=111 -| | | | | |=== [cols="<,<,<,<,<",] @@ -799,7 +791,6 @@ rm=111 |FCVT.D.WU |_rs1_ |_rd_ | | -| | | | | |=== [cols="<,<,<,<,<",] @@ -826,6 +817,5 @@ rm=111 |FMV.D.X |_rs1_ |_rd_ | | -| | | | | |=== diff --git a/src/zicsr.adoc b/src/zicsr.adoc index aabe032..aeec2a4 100644 --- a/src/zicsr.adoc +++ b/src/zicsr.adoc @@ -1,5 +1,5 @@ [[csrinsts]] -== `Zicsr`, Control and Status Register (CSR) Instructions, Version 2.0 +== ZICSR Control and Status Register (CSR) Instructions, Version 2.0 RISC-V defines a separate address space of 4096 Control and Status registers associated with each hart. This chapter defines the full set |