Fix wording and formatting of x0 special cases (#1770)

* Restore semicolons in "C" Extension spec

Removed in aaad788

* "is only valid when" -> "is valid only when"

* Consistent formatting of "(not) equal x0"

src/c-st-ext.adoc

@@ -306,21 +306,21 @@ These instructions use the CI format.
 C.LWSP loads a 32-bit value from memory into register _rd_. It computes
 an effective address by adding the _zero_-extended offset, scaled by 4,
 to the stack pointer, `x2`. It expands to `lw rd, offset(x2)`. C.LWSP is
-only valid when _rd_≠x0 the code points with _rd_=x0 are reserved.
+valid only when _rd_≠`x0`; the code points with _rd_=`x0` are reserved.
 
 C.LDSP is an RV64C/RV128C-only instruction that loads a 64-bit value
 from memory into register _rd_. It computes its effective address by
 adding the zero-extended offset, scaled by 8, to the stack pointer,
-`x2`. It expands to `ld rd, offset(x2)`. C.LDSP is only valid when
-_rd_≠x0 the code points with
-_rd_=x0 are reserved.
+`x2`. It expands to `ld rd, offset(x2)`. C.LDSP is valid only when
+_rd_≠`x0`; the code points with
+_rd_=`x0` are reserved.
 
 C.LQSP is an RV128C-only instruction that loads a 128-bit value from
 memory into register _rd_. It computes its effective address by adding
 the zero-extended offset, scaled by 16, to the stack pointer, `x2`. It
-expands to `lq rd, offset(x2)`. C.LQSP is only valid when
-_rd_≠x0 the code points with
-_rd_=x0 are reserved.
+expands to `lq rd, offset(x2)`. C.LQSP is valid only when
+_rd_≠`x0`; the code points with
+_rd_=`x0` are reserved.
 
 C.FLWSP is an RV32FC-only instruction that loads a single-precision
 floating-point value from memory into floating-point register _rd_. It
@@ -515,15 +515,15 @@ These instructions use the CR format.
 
 C.JR (jump register) performs an unconditional control transfer to the
 address in register _rs1_. C.JR expands to `jalr x0, 0(rs1)`. C.JR is
-only valid when latexmath:[$\textit{rs1}{\neq}\texttt{x0}$]; the code
-point with latexmath:[$\textit{rs1}{=}\texttt{x0}$] is reserved.
+valid only when _rs1_≠`x0`; the code
+point with _rs1_=`x0` is reserved.
 
 C.JALR (jump and link register) performs the same operation as C.JR, but
 additionally writes the address of the instruction following the jump
 (`pc`+2) to the link register, `x1`. C.JALR expands to
-`jalr x1, 0(rs1)`. C.JALR is only valid when
-latexmath:[$\textit{rs1}{\neq}\texttt{x0}$]; the code point with
-latexmath:[$\textit{rs1}{=}\texttt{x0}$] corresponds to the C.EBREAK
+`jalr x1, 0(rs1)`. C.JALR is valid only when
+_rs1_≠`x0`; the code point with
+_rs1_=`x0` corresponds to the C.EBREAK
 instruction.
 
 [NOTE]
@@ -568,14 +568,14 @@ include::images/wavedrom/c-integer-const-gen.edn[]
 
 
 C.LI loads the sign-extended 6-bit immediate, _imm_, into register _rd_.
-C.LI expands into `addi rd, x0, imm`. C.LI is only valid when
-`_rd_≠x0`; the code points with `_rd_=x0` encode HINTs.
+C.LI expands into `addi rd, x0, imm`. C.LI is valid only when
+_rd_≠`x0`; the code points with _rd_=`x0` encode HINTs.
 
 C.LUI loads the non-zero 6-bit immediate field into bits 17–12 of the
 destination register, clears the bottom 12 bits, and sign-extends bit 17
 into all higher bits of the destination. C.LUI expands into
-`lui rd, imm`. C.LUI is only valid when 
-latexmath:[$\textit{rd}{\neq}{\left\{\texttt{x0},\texttt{x2}\right\}}$],
+`lui rd, imm`. C.LUI is valid only when
+_rd_≠{`x0`,`x2`},
 and when the immediate is not equal to zero. The code points with
 _imm_=0 are reserved; the remaining code points with _rd_=`x0` are
 HINTs; and the remaining code points with _rd_=`x2` correspond to the
@@ -593,25 +593,25 @@ include::images/wavedrom/c-int-reg-immed.edn[]
 
 C.ADDI adds the non-zero sign-extended 6-bit immediate to the value in
 register _rd_ then writes the result to _rd_. C.ADDI expands into
-`addi rd, rd, imm`. C.ADDI is only valid when
-`_rd_≠x0` and `_imm_≠0`. The code
-points with `_rd_=x0` encode the C.NOP instruction; the remaining code
+`addi rd, rd, imm`. C.ADDI is valid only when
+_rd_≠`x0` and _imm_≠0. The code
+points with _rd_=`x0` encode the C.NOP instruction; the remaining code
 points with _imm_=0 encode HINTs.
 
 C.ADDIW is an RV64C/RV128C-only instruction that performs the same
 computation but produces a 32-bit result, then sign-extends result to 64
 bits. C.ADDIW expands into `addiw rd, rd, imm`. The immediate can be
 zero for C.ADDIW, where this corresponds to `sext.w rd`. C.ADDIW is
-only valid when `_rd_≠x0`; the code points with
-`_rd_=x0` are reserved.
+valid only when _rd_≠`x0`; the code points with
+_rd_=`x0` are reserved.
 
 C.ADDI16SP (add immediate to stack pointer)
 shares the opcode with C.LUI, but has a destination field of
 `x2`. C.ADDI16SP adds the non-zero sign-extended 6-bit immediate to the
 value in the stack pointer (`sp=x2`), where the immediate is scaled to
 represent multiples of 16 in the range [-512, 496]. C.ADDI16SP is used to
 adjust the stack pointer in procedure prologues and epilogues. It
-expands into `addi x2, x2, nzimm[9:4]`. C.ADDI16SP is only valid when
+expands into `addi x2, x2, nzimm[9:4]`. C.ADDI16SP is valid only when
 _nzimm_≠0; the code point with _nzimm_=0 is reserved.
 
 [NOTE]
@@ -629,7 +629,7 @@ is a CIW-format instruction that adds a _zero_-extended
 non-zero immediate, scaled by 4, to the stack pointer, `x2`, and writes
 the result to `rd′`. This instruction is used to generate
 pointers to stack-allocated variables, and expands to
-`addi rd′, x2, nzuimm[9:2]`. C.ADDI4SPN is only valid when
+`addi rd′, x2, nzuimm[9:2]`. C.ADDI4SPN is valid only when
 _nzuimm_≠0; the code points with _nzuimm_=0 are
 reserved.
 
@@ -648,7 +648,7 @@ zero is used to encode a shift of 64. C.SLLI expands into
 For RV32C, _shamt[5]_ must be zero; the code points with _shamt[5]_=1
 are designated for custom extensions. For RV32C and RV64C, the shift
 amount must be non-zero; the code points with _shamt_=0 are HINTs. For
-all base ISAs, the code points with `_rd_=x0` are HINTs, except those
+all base ISAs, the code points with _rd_=`x0` are HINTs, except those
 with _shamt[5]_=1 in RV32C.
 
 [[c-srli-srai]]
@@ -706,8 +706,8 @@ include::images/wavedrom/c-int-reg-to-reg-cr-format.edn[]
 These instructions use the CR format.
 
 C.MV copies the value in register _rs2_ into register _rd_. C.MV expands
-into `add rd, x0, rs2`. C.MV is only valid when
-`rs2≠x0` the code points with `rs2=x0` correspond to the C.JR instruction. The code points with `rs2≠x0` and `rd=x0` are HINTs.
+into `add rd, x0, rs2`. C.MV is valid only when
+_rs2_≠`x0`; the code points with _rs2_=`x0` correspond to the C.JR instruction. The code points with _rs2_≠`x0` and _rd_=`x0` are HINTs.
 
 [NOTE]
 ====
@@ -720,8 +720,8 @@ 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
-valid when `rs2≠x0` the code points with `rs2=x0` correspond to the C.JALR
-and C.EBREAK instructions. The code points with `rs2≠x0` and rd=x0 are HINTs.
+valid when _rs2_≠`x0`; the code points with _rs2_=`x0` correspond to the C.JALR
+and C.EBREAK instructions. The code points with _rs2_≠`x0` and _rd_=`x0` are HINTs.
 
 [[c-ca]]
 include::images/wavedrom/c-int-reg-to-reg-ca-format.edn[]
@@ -798,7 +798,7 @@ include::images/wavedrom/c-nop-instr.edn[]
 
 `C.NOP` is a CI-format instruction that does not change any user-visible
 state, except for advancing the `pc` and incrementing any applicable
-performance counters. `C.NOP` expands to `nop`. `C.NOP` is only valid when
+performance counters. `C.NOP` expands to `nop`. `C.NOP` is valid only when
 _imm_=0; the code points with _imm_≠0 encode HINTs.
 
 ==== Breakpoint Instruction
@@ -889,7 +889,7 @@ no standard HINTs will ever be defined in this subspace.
 
 |C.SLLI |_rd_=`x0`, _imm_≠0 |31 (RV32), 63 (RV64/128)  .5+.^|_Designated for custom use_
 
-|C.SLLI64 | _rd_=_x0_ |1
+|C.SLLI64 | _rd_=`x0` |1
 
 |C.SLLI64 | _rd_≠`x0`, RV32 and RV64 only |31
 

src/rv32.adoc

@@ -975,7 +975,7 @@ performance counters. Implementations are always allowed to ignore the
 encoded hints.
 
 Most RV32I HINTs are encoded as integer computational instructions with
-_rd_=x0. The other RV32I HINTs are encoded as FENCE instructions with
+_rd_=`x0`. The other RV32I HINTs are encoded as FENCE instructions with
 a null predecessor or successor set and with _fm_=0.
 
 [NOTE]

src/scalar-crypto.adoc

@@ -3560,7 +3560,7 @@ The 32-bit contents of `seed` are as follows:
 |=======================================================================
 
 Attempts to access the `seed` CSR using a read-only CSR-access instruction
-(`CSRRS`/`CSRRC` with `rs1=x0` or `CSRRSI`/`CSRRCI` with `uimm=0`) raise an
+(`CSRRS`/`CSRRC` with _rs1_=`x0` or `CSRRSI`/`CSRRCI` with _uimm_=0) raise an
 illegal instruction exception; any other CSR-access instruction may be used
 to access `seed`.
 The write value (in `rs1` or `uimm`) must be ignored by implementations.
@@ -3970,7 +3970,7 @@ specific zeroization/sanitisation or by being declared ciphertext
 
 ==== Specific Instruction Rationale
 
-* HINT instruction forms (typically encodings with `rd=x0`) are excluded from
+* HINT instruction forms (typically encodings with _rd_=`x0`) are excluded from
 the data-independent time requirement. 
 * Floating point (F, D, Q, L extensions) are currently excluded from the
 constant-time requirement as they have very few applications in standardised

src/smctr.adoc

@@ -673,7 +673,7 @@ _Though this compressed method of representation results in some imprecision for
 
 The CC value saturates when all implemented bits in CCM and CCE are 1.
 
-The CC value is only valid when the Cycle Count Valid (CCV) bit is set.  If CCV=0, the CC value might not hold the correct count of elapsed active cycles since the last recorded transfer.  The next record will have CCV=0 after a write to `__x__ctrctl`, or execution of SCTRCLR, since CtrCycleCounter is reset.  CCV should additionally be cleared after any other implementation-specific scenarios where active cycles might not be counted in CtrCycleCounter.
+The CC value is valid only when the Cycle Count Valid (CCV) bit is set.  If CCV=0, the CC value might not hold the correct count of elapsed active cycles since the last recorded transfer.  The next record will have CCV=0 after a write to `__x__ctrctl`, or execution of SCTRCLR, since CtrCycleCounter is reset.  CCV should additionally be cleared after any other implementation-specific scenarios where active cycles might not be counted in CtrCycleCounter.
 
 ==== RAS (Return Address Stack) Emulation Mode
 

src/unpriv-cfi.adoc

@@ -40,18 +40,18 @@ return from procedure if `rs1` is a conventional link register (i.e. `x1` or
 `x5`); else it is an indirect jump.
 
 The term _call_ is used to refer to a `JAL` or `JALR` instruction with a link
-register as destination, i.e., `rd != x0`. Conventionally, the link register is
+register as destination, i.e., _rd_≠`x0`. Conventionally, the link register is
 `x1` or `x5`. A _call_ using `JAL` or `C.JAL` is termed a direct call. A
 `C.JALR` expands to `JALR x1, 0(rs1)` and is a _call_. A _call_ using `JALR` or
 `C.JALR` is termed an _indirect-call_.
 
-The term _return_ is used to refer to a `JALR` instruction with `rd == x0` and
-with `rs1 == x1` or `rs1 == x5`. A `C.JR` instruction expands to 
-`JALR x0, 0(rs1)` and is a _return_ if `rs1 == x1` or `rs1 == x5`.
+The term _return_ is used to refer to a `JALR` instruction with _rd_=`x0` and
+with _rs1_=`x1` or _rs1_=`x5`. A `C.JR` instruction expands to
+`JALR x0, 0(rs1)` and is a _return_ if _rs1_=`x1` or _rs1_=`x5`.
 
-The term _indirect-jump_ is used to refer to a `JALR` instruction with `rd == x0`
-and where the `rs1` is not `x1` or `x5` (i.e., not a return). A `C.JR`
-instruction where `rs1` is not `x1` or `x5` (i.e., not a return) is an
+The term _indirect-jump_ is used to refer to a `JALR` instruction with _rd_=`x0`
+and where the _rs1_ is not `x1` or `x5` (i.e., not a return). A `C.JR`
+instruction where _rs1_ is not `x1` or `x5` (i.e., not a return) is an
 _indirect-jump_.
 
 The Zicfiss and Zicfilp extensions build on these conventions and hints and
@@ -69,7 +69,7 @@ To enforce forward-edge control-flow integrity, the Zicfilp extension introduces
 a landing pad (`LPAD`) instruction. The `LPAD` instruction must be placed at the
 program locations that are valid targets of indirect jumps or calls. The `LPAD`
 instruction (See <<LP_INST>>) is encoded using the `AUIPC` major opcode with
-`rd=x0`.
+_rd_=`x0`.
 
 Compilers emit a landing pad instruction as the first instruction of an
 address-taken function, as well as at any indirect jump targets. A landing pad
@@ -656,7 +656,7 @@ register.
 ], config:{lanes: 1, hspace:1024}}
 ....
 
-Encoding `rd` as `x0` is not supported for `SSRDP`.
+Encoding _rd_ as `x0` is not supported for `SSRDP`.
 
 The operation of the `SSRDP` instructions is as follows:
 

src/v-st-ext.adoc

@@ -1222,15 +1222,15 @@ fields as follows:
 |  x0    |  x0    | Value in `vl` register | Keep existing `vl` (of course, `vtype` may change)
 |===
 
-When `rs1` is not `x0`, the AVL is an unsigned integer held in the `x`
-register specified by `rs1`, and the new `vl` value is also written to
-the `x` register specified by `rd`.
+When _rs1_ is not `x0`, the AVL is an unsigned integer held in the `x`
+register specified by _rs1_, and the new `vl` value is also written to
+the `x` register specified by _rd_.
 
-When `rs1=x0` but `rd!=x0`, the maximum unsigned integer value (`~0`)
+When _rs1_=`x0` but _rd_≠`x0`, the maximum unsigned integer value (`~0`)
 is used as the AVL, and the resulting VLMAX is written to `vl` and
 also to the `x` register specified by `rd`.
 
-When `rs1=x0` and `rd=x0`, the instruction operates as if the current
+When _rs1_=`x0` and _rd_=`x0`, the instruction operates as if the current
 vector length in `vl` is used as the AVL, and the resulting value is
 written to `vl`, but not to a destination register.  This form can
 only be used when VLMAX and hence `vl` is not actually changed by the

src/zpm.adoc

@@ -274,7 +274,7 @@ Guest physical addresses (GPAs) are 2 bits wider than the corresponding virtual
 An implementation could mask those two bits on the TLB access path, but this can have a significant timing impact. Alternatively, an implementation may choose to "waste" TLB capacity by having up to 4 duplicate entries for each page. In this case, the pointer masking operation can be applied on the TLB refill path, where it is unlikely to affect timing. To support this approach, some TLB entries need to be flushed when PMLEN changes in a way that may affect these duplicate entries.
 ====
 
-To support implementations where (XLEN-PMLEN) can be less than the GPA width supported by `hgatp.MODE`, hypervisors should execute an `HFENCE.GVMA` with rs1=x0 if the `henvcfg.PMM` is changed from or to a value where (XLEN-PMLEN) is less than GPA width supported by the `hgatp` translation mode of that guest. Specifically, these cases are:
+To support implementations where (XLEN-PMLEN) can be less than the GPA width supported by `hgatp.MODE`, hypervisors should execute an `HFENCE.GVMA` with _rs1_=`x0` if the `henvcfg.PMM` is changed from or to a value where (XLEN-PMLEN) is less than GPA width supported by the `hgatp` translation mode of that guest. Specifically, these cases are:
 
 * `PMLEN=7` and `hgatp.MODE=sv57x4`
 * `PMLEN=16` and `hgatp.MODE=sv57x4`