Use plural "base ISAs" rather than "base ISA" when appropriate

cc @gfavor @kasanovic

7 files changed, 18 insertions, 17 deletions

diff --git a/src/b.tex b/src/b.tex
index 0951df4..0c4e497 100644
--- a/src/b.tex
+++ b/src/b.tex
@@ -9,7 +9,7 @@ shifts, and bit and byte permutations.
 \begin{commentary}
 Although bit manipulation instructions are very effective in some
 application domains, particularly when dealing with externally packed
-data structures, we excluded them from the base ISA as they are not
+data structures, we excluded them from the base ISAs as they are not
 useful in all domains and can add additional complexity or instruction
 formats to supply all needed operands.
 
diff --git a/src/c.tex b/src/c.tex
index 0a26877..fc174da 100644
--- a/src/c.tex
+++ b/src/c.tex
@@ -39,7 +39,7 @@ instructions allows significantly greater code density.
 
 The compressed instruction encodings are mostly common across RV32C,
 RV64C, and RV128C, but as shown in Table~\ref{rvcopcodemap}, a few
-opcodes are used for different purposes depending on base ISA width.
+opcodes are used for different purposes depending on base ISA.
 For example, the wider address-space RV64C and RV128C variants require
 additional opcodes to compress loads and stores of 64-bit integer
 values, while RV32C uses the same opcodes to compress loads and stores
@@ -73,9 +73,9 @@ Short-range subroutine calls are more likely in small binaries for
 microcontrollers, hence the motivation to include these in RV32C.
 
 Although reusing opcodes for different purposes for different base
-register widths adds some complexity to documentation, the impact on
+ISAs adds some complexity to documentation, the impact on
 implementation complexity is small even for designs that support
-multiple base ISA register widths.  The compressed floating-point load
+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.
 \end{commentary}
diff --git a/src/csr.tex b/src/csr.tex
index 266e02a..539f42e 100644
--- a/src/csr.tex
+++ b/src/csr.tex
@@ -12,7 +12,7 @@ set of CSR instructions that operate on these CSRs.
 
   The counters and timers are no longer considered mandatory parts of
   the standard base ISAs, and so the CSR instructions required to
-  access them have been moved out of the base ISA chapter into this
+  access them have been moved out of Chapter~\ref{rv32} into this
   separate chapter.
 \end{commentary}
 
diff --git a/src/extensions.tex b/src/extensions.tex
index a9050a1..56cc912 100644
--- a/src/extensions.tex
+++ b/src/extensions.tex
@@ -48,7 +48,7 @@ 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 ISA is defined within a 30-bit encoding space (bits
+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).
 
@@ -117,7 +117,8 @@ Note that we consider the standard A extension to have a greenfield
 encoding as it defines a new previously empty 25-bit encoding space in
 the leftmost bits of the full 32-bit base instruction encoding, even
 though its standard prefix locates it within the 30-bit encoding space
-of the base ISA.  Changing only its single 7-bit prefix could move the
+of its parent base ISA.
+Changing only its single 7-bit prefix could move the
 A extension to a different 30-bit encoding space while only worrying
 about conflicts at the prefix level, not within the encoding space
 itself.
@@ -201,7 +202,7 @@ standard-compatible global encodings can be used in a number of ways.
 One use-case is developing highly specialized custom accelerators,
 designed to run kernels from important application domains.  These
 might want to drop all but the base integer ISA and add in only the
-extensions that are required for the task in hand.  The base ISA has
+extensions that are required for the task in hand.  The base ISAs have
 been designed to place minimal requirements on a hardware
 implementation, and has been encoded to use only a small fraction of a
 32-bit instruction encoding space.
@@ -376,7 +377,7 @@ unaware of the VLIW extension would have both prefix bits set (11) and
 thus have the correct semantics, with each instruction at the end of a
 group and not predicated.
 
-The main disadvantage of this approach is that the base ISA lacks the
+The main disadvantage of this approach is that the base ISAs lack the
 complex predication support usually required in an aggressive VLIW
 system, and it is difficult to add space to specify more predicate
 registers in the standard 30-bit encoding space.
diff --git a/src/f.tex b/src/f.tex
index c7d7251..81545fd 100644
--- a/src/f.tex
+++ b/src/f.tex
@@ -274,7 +274,7 @@ exception flag.
 
 \begin{commentary}
 As allowed by the standard, we do not support traps on floating-point
-exceptions in the base ISA, but instead require explicit checks of the flags
+exceptions in the F extension, but instead require explicit checks of the flags
 in software.  We considered adding branches controlled directly by the
 contents of the floating-point accrued exception flags, but ultimately chose
 to omit these instructions to keep the ISA simple.
@@ -324,7 +324,7 @@ Detecting tininess after rounding results in fewer spurious underflow signals.
 \section{Single-Precision Load and Store Instructions}
 
 Floating-point loads and stores use the same base+offset addressing
-mode as the integer base ISA, with a base address in register {\em
+mode as the integer base ISAs, with a base address in register {\em
   rs1} and a 12-bit signed byte offset.  The FLW instruction loads a
 single-precision floating-point value from memory into floating-point
 register {\em rd}.  FSW stores a single-precision value from
@@ -734,7 +734,7 @@ FMV.W.X & S & 0    & src  & 000  & dest & OP-FP  \\
 The base floating-point ISA was defined so as to allow implementations
 to employ an internal recoding of the floating-point format in
 registers to simplify handling of subnormal values and possibly to
-reduce functional unit latency.  To this end, the base ISA avoids
+reduce functional unit latency.  To this end, the F extension avoids
 representing integer values in the floating-point registers by
 defining conversion and comparison operations that read and write the
 integer register file directly.  This also removes many of the common
@@ -784,7 +784,7 @@ FCMP & S & src2 & src1 & EQ/LT/LE & dest & OP-FP  \\
 \end{center}
 
 \begin{commentary}
-The F extension provides a $\leq$ comparison, whereas the base ISA provides
+The F extension provides a $\leq$ comparison, whereas the base ISAs provide
 a $\geq$ branch comparison.  Because $\leq$ can be synthesized from $\geq$ and
 vice-versa, there is no performance implication to this inconsistency, but it
 is nevertheless an unfortunate incongruity in the ISA.
diff --git a/src/machine.tex b/src/machine.tex
index 1a6a618..4056c80 100644
--- a/src/machine.tex
+++ b/src/machine.tex
@@ -49,7 +49,7 @@ mechanism.
 
 The MXL (Machine XLEN) field encodes the native base integer ISA width
 as shown in Table~\ref{misabase}.  The MXL field may be writable in
-implementations that support multiple base ISA widths.  The effective
+implementations that support multiple base ISAs.  The effective
 XLEN in M-mode, {\em MXLEN}, is given by the setting of MXL, or has a
 fixed value if {\tt misa} is zero.  The MXL field is always set to the
 widest supported ISA variant at reset.
diff --git a/src/rv32.tex b/src/rv32.tex
index e9e6ff8..afc6730 100644
--- a/src/rv32.tex
+++ b/src/rv32.tex
@@ -130,7 +130,7 @@ high-performance code, where there can be extensive use of loop
 unrolling, software pipelining, and cache tiling.
 
 For these reasons, we chose a conventional size of 32 integer
-registers for the base ISA.  Dynamic register usage tends to be
+registers for RV32I.  Dynamic register usage tends to be
 dominated by a few frequently accessed registers, and regfile
 implementations can be optimized to reduce access energy for the
 frequently accessed registers~\cite{jtseng:sbbci}.  The optional
@@ -1128,7 +1128,7 @@ packed-SIMD extension or handling externally packed data structures.
 Our rationale for allowing EEIs to choose to support misaligned
 accesses via the regular load and store instructions is to simplify
 the addition of misaligned hardware support.  One option would have
-been to disallow misaligned accesses in the base ISA and then provide
+been to disallow misaligned accesses in the base ISAs and then provide
 some separate ISA support for misaligned accesses, either special
 instructions to help software handle misaligned accesses or a new
 hardware addressing mode for misaligned accesses.  Special
@@ -1351,7 +1351,7 @@ supervisor-level operating system or debugger.
   Another use of EBREAK is to support ``semihosting'', where the
   execution environment includes a debugger that can provide services
   over an alternate system call interface built around the EBREAK
-  instruction.  Because the RISC-V base ISA does not provide more than
+  instruction.  Because the RISC-V base ISAs do not provide more than
   one EBREAK instruction, RISC-V semihosting uses a special sequence of
   instructions to distinguish a semihosting EBREAK from a debugger
   inserted EBREAK.