some table fixes and additions of missing formatting

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
index 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