Fixed quotes that converted incorrectly and table refs.

Fixed quotes that did not convert correctly.
Added new displayed text for table refs.

1 files changed, 14 insertions, 14 deletions

diff --git a/src/extending.adoc b/src/extending.adoc
index a7c319d..965f1f3 100644
--- a/src/extending.adoc
+++ b/src/extending.adoc
@@ -31,7 +31,7 @@ categories: _standard_ versus _non-standard_.
 
 * A standard extension is one that is generally useful and that is
 designed to not conflict with any other standard extension. Currently,
-`MAFDQLCBTPV`, described in other chapters of this manual, are either
+"MAFDQLCBTPV", described in other chapters of this manual, are either
 complete or planned standard extensions.
 * A non-standard extension may be highly specialized and may conflict
 with other standard or non-standard extensions. We anticipate a wide
@@ -44,17 +44,17 @@ An instruction encoding space is some number of instruction bits within
 which a base ISA or ISA extension is encoded. RISC-V supports varying
 instruction lengths, but even within a single instruction length, there
 are various sizes of encoding space available. For example, the base
-ISAs are defined within a 30-bit encoding space (bits 31–2 of the 32-bit
-instruction), while the atomic extension ``A`` fits within a 25-bit
-encoding space (bits 31–7).
+ISAs are defined within a 30-bit encoding space (bits 31-2 of the 32-bit
+instruction), while the atomic extension "A" fits within a 25-bit
+encoding space (bits 31-7).
 
 We use the term _prefix_ to refer to the bits to the _right_ of an
 instruction encoding space (since instruction fetch in RISC-V is
 little-endian, the bits to the right are stored at earlier memory
 addresses, hence form a prefix in instruction-fetch order). The prefix
-for the standard base ISA encoding is the two-bit `11` field held in
-bits 1–0 of the 32-bit word, while the prefix for the standard atomic
-extension `A` is the seven-bit `0101111` field held in bits 6–0 of
+for the standard base ISA encoding is the two-bit "11" field held in
+bits 1-0 of the 32-bit word, while the prefix for the standard atomic
+extension "A" is the seven-bit "0101111" field held in bits 6-0 of
 the 32-bit word representing the AMO major opcode. A quirk of the
 encoding format is that the 3-bit funct3 field used to encode a minor
 opcode is not contiguous with the major opcode bits in the 32-bit
@@ -64,7 +64,7 @@ instruction spaces.
 Although an instruction encoding space could be of any size, adopting a
 smaller set of common sizes simplifies packing independently developed
 extensions into a single global encoding.
-<<encodingspaces>> gives the suggested sizes for RISC-V.
+<<encodingspaces, Table 40>> gives the suggested sizes for RISC-V.
 
 [[encodingspaces]]
 .Suggested standard RISC-V instruction encoding space sizes.
@@ -136,7 +136,7 @@ itself.
 |Brownfield |F(I), D(F), Q(D)     |M(I)
 |===
 
-<<exttax>> shows the bases and standard extensions placed
+<<exttax, Table 41>> shows the bases and standard extensions placed
 in a simple two-dimensional taxonomy. One axis is whether the extension
 is greenfield or brownfield, while the other axis is whether the
 extension adds architectural state. For greenfield extensions, the size
@@ -243,7 +243,7 @@ A 25-bit instruction encoding space corresponds to a major opcode in the
 base and standard extension encodings.
 
 There are four major opcodes expressly designated for custom extensions
-<<opcodemap>>, each of which represents a 25-bit
+<<opcodemap, Table 38>>, each of which represents a 25-bit
 encoding space. Two of these are reserved for eventual use in the RV128
 base encoding (will be OP-IMM-64 and OP-64), but can be used for
 non-standard extensions for RV32 and RV64.
@@ -259,7 +259,7 @@ if the standard atomic extensions are not required.
 
 If an implementation does not require instructions longer than 32-bits,
 then an additional four major opcodes are available (those marked in
-gray in <<opcodemap>>.
+gray in <<opcodemap, Table 38>>.
 
 The base RV32I encoding uses only 11 major opcodes plus 3 reserved
 opcodes, leaving up to 18 available for extensions. The base RV64I
@@ -293,7 +293,7 @@ are aligned on 64-bit boundaries to simplify instruction fetch, with a
 32-bit NOP instruction used as alignment padding where necessary.
 
 To simplify use of standard tools, the 64-bit instructions should be
-encoded as described in <<instlengthcode>>.
+encoded as described in <<instlengthcode, Table 1>>.
 However, an implementation might choose a non-standard
 instruction-length encoding for 64-bit instructions, while retaining the
 standard encoding for 32-bit instructions. For example, if compressed
@@ -324,7 +324,7 @@ VLIW code size expansion to VLIW-accelerated functions.
 ==== Encoded-Length Groups
 
 Another approach is to use the standard length encoding from
-<<instlengthcode>> to encode parallel
+<<instlengthcode, Table 1>> to encode parallel
 instruction groups, allowing NOPs to be compressed out of the VLIW
 instruction. For example, a 64-bit instruction could hold two 28-bit
 operations, while a 96-bit instruction could hold three 28-bit
@@ -354,7 +354,7 @@ to be supported.
 None of the above approaches retains the RISC-V encoding for the
 individual operations within a VLIW instruction. Yet another approach is
 to repurpose the two prefix bits in the fixed-width 32-bit encoding. One
-prefix bit can be used to signal `end-of-group` if set, while the
+prefix bit can be used to signal "end-of-group" if set, while the
 second bit could indicate execution under a predicate if clear. Standard
 RISC-V 32-bit instructions generated by tools unaware of the VLIW
 extension would have both prefix bits set (11) and thus have the correct