Several Ch. 11 fixes.

Added back in the admonitions.
Updated ref. to memorymodel chapters.
Cleaned up all conversion issues.

1 files changed, 34 insertions, 32 deletions

diff --git a/src/zicsr.adoc b/src/zicsr.adoc
index fcb19c4..b057fce 100644
--- a/src/zicsr.adoc
+++ b/src/zicsr.adoc
@@ -21,7 +21,7 @@ chapter.
 
 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
+held in bits 31-20. The immediate forms use a 5-bit zero-extended
 immediate encoded in the _rs1_ field.
 
 include::images/wavedrom/csr-instr.adoc[]
@@ -29,7 +29,7 @@ include::images/wavedrom/csr-instr.adoc[]
 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`,
+_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.
 
@@ -49,15 +49,15 @@ 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.
 
-For both CSRRS and CSRRC, if _rs1_=`x0`, then the instruction will not
+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
+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
+effects. A CSRRW with _rs1_='x0' will attempt to write zero to the
 destination CSR.
 
 The CSRRWI, CSRRSI, and CSRRCI variants are similar to CSRRW, CSRRS, and
@@ -68,7 +68,7 @@ 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
+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.
@@ -78,29 +78,28 @@ effects regardless of _rd_ and _rs1_ fields.
 [cols="^,^,^,^,^",options="header",]
 |===
 5+|Register operand 
-|Instruction |_rd_ is `x0` |_rs1_ is `x0` |Reads CSR |Writes CSR
+|Instruction |_rd_ is 'x0' |_rs1_ is 'x0' |Reads CSR |Writes CSR
 
-|CSRRW |Yes |– |No |Yes
+|CSRRW |Yes |- |No |Yes
 
-|CSRRW |No |– |Yes |Yes
+|CSRRW |No |- |Yes |Yes
 
-|CSRRS/CSRRC |– |Yes |Yes |No
+|CSRRS/CSRRC |- |Yes |Yes |No
 
-|CSRRS/CSRRC |– |No |Yes |Yes
+|CSRRS/CSRRC |- |No |Yes |Yes
 
-[cols=]
 5+|Immediate operand 
 
-|Instruction |_rd_ is `x0` |__uimm__latexmath:[$=$]0 |Reads CSR |Writes
+|Instruction |_rd_ is 'x0' |__uimm__latexmath:[$=$]0 |Reads CSR |Writes
 CSR
 
-|CSRRWI |Yes |– |No |Yes
+|CSRRWI |Yes |- |No |Yes
 
-|CSRRWI |No |– |Yes |Yes
+|CSRRWI |No |- |Yes |Yes
 
-|CSRRSI/CSRRCI |– |Yes |Yes |No
+|CSRRSI/CSRRCI |- |Yes |Yes |No
 
-|CSRRSI/CSRRCI |– |No |Yes |Yes
+|CSRRSI/CSRRCI |- |No |Yes |Yes
 |===
 
 <<csrsideeffects>> summarizes the behavior of the CSR
@@ -111,7 +110,8 @@ 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.
-
+[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
@@ -128,7 +128,7 @@ 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.
 
-More concretely, the RISC-V privileged architecture defined in Volume II
+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 merely
@@ -137,13 +137,13 @@ 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.
-
-Some CSRs, such as the instructions-retired counter, `instret`, may be
+====
+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
+written to 'instret' by one instruction will be the value read by the
 following instruction.
 
 The assembler pseudoinstruction to read a CSR, CSRR _rd, csr_, is
@@ -175,8 +175,7 @@ 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.)
 
-For the RVWMO memory consistency model
-(<<memorymodel>>), CSR accesses are weakly
+For the RVWMO memory consistency model (<<memorymodel>>), 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
@@ -189,7 +188,8 @@ 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).
-
+[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
@@ -199,21 +199,23 @@ order of memory-mapped I/O accesses to such a region.
 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 (e.g., taking an interrupt because of a change in `mip`) are
+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 (e.g., taking an interrupt because of a change in 'mip') are
 also ordered as device input.
 
-Most CSRs (including, e.g., the `fcsr`) are not visible to other harts;
+Most CSRs (including, e.g., 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.
-
+====
 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 and accesses to memory-mapped I/O regions.
 
+[NOTE]
+====
 The rules for the reordering of CSR accesses in the global memory order
-should probably be moved to Chapter #ch:memorymodel[[ch:memorymodel]]
-concerning the RVWMO memory consistency model.
+should probably be moved to <<memorymodel>> concerning the RVWMO memory consistency model.
+====
\ No newline at end of file