Merge pull request riscv#1805 from riscv/redundant-section

Remove redundant "Section" words

Author: aswaterman

src/machine.adoc

@@ -2829,7 +2829,9 @@ and I/O regions may be accessed with either _relaxed_ or _strong_
 ordering. Accesses to an I/O region with relaxed ordering are generally
 observed by other harts and bus mastering devices in a manner similar to
 the ordering of accesses to an RVWMO memory region, as discussed in
-Section A.4.2 in Volume I of this specification. By contrast, accesses
+the I/O Ordering section in the RVWMO Explanatory Material appendix
+of Volume I of this specification.
+By contrast, accesses
 to an I/O region with strong ordering are generally observed by other
 harts and bus mastering devices in program order.
 

src/mm-formal.adoc

@@ -255,7 +255,7 @@ input and simulates the execution of the test on top of the memory
 model. Memory models are written in the domain specific language Cat.
 This section provides two Cat memory model of RVWMO. The first model,
 <<herd2>>, follows the _global memory order_,
-Chapter <<memorymodel>>, definition of RVWMO, as much
+<<memorymodel>>, definition of RVWMO, as much
 as is possible for a Cat model. The second model,
 <<herd3>>, is an equivalent, more efficient,
 partial order based RVWMO model.

src/scalar-crypto.adoc

@@ -4657,7 +4657,7 @@ SP 800-90C cite:[BaKeRo:21] states that each conditioned block of n bits
 is required to have n+64 bits of input entropy to attain full entropy.
 Hence NIST SP 800-90B cite:[TuBaKe:18] min-entropy assessment must
 guarantee at least 128 + 64 = 192 bits input entropy per 256-bit block
-( cite:[BaKeRo:21], Sections 4.1. and 4.3.2 ).
+(cite:[BaKeRo:21], Sections 4.1. and 4.3.2).
 Only then a hashing of 16 * 16 = 256 bits from the entropy source
 will produce the desired 128 bits of full entropy. This follows from
 the specific requirements, threat model, and distinguishability proof

src/v-st-ext.adoc

@@ -15,7 +15,7 @@ This spec includes the complete set of currently frozen vector
 instructions.  Other instructions that have been considered during
 development but are not present in this document are not included in
 the review and ratification process, and may be completely revised or
-abandoned.  Section <<sec-vector-extensions>> lists the standard
+abandoned.  <<sec-vector-extensions>> lists the standard
 vector extensions and which instructions and element widths are
 supported by each extension.
 
@@ -27,7 +27,7 @@ Each hart supporting a vector extension defines two parameters:
 must be a power of 2.
 . The number of bits in a single vector register, _VLEN_ {ge} ELEN, which must be a power of 2, and must be no greater than 2^16^.
 
-Standard vector extensions (Section <<sec-vector-extensions>>) and
+Standard vector extensions (<<sec-vector-extensions>>) and
 architecture profiles may set further constraints on _ELEN_ and _VLEN_.
 
 NOTE: Future extensions may allow ELEN {gt} VLEN by holding one
@@ -350,7 +350,7 @@ These two bits modify the behavior of destination tail elements and
 destination inactive masked-off elements respectively during the
 execution of vector instructions.  The tail and inactive sets contain
 element positions that are not receiving new results during a vector
-operation, as defined in Section <<sec-inactive-defs>>.
+operation, as defined in <<sec-inactive-defs>>.
 
 All systems must support all four options:
 
@@ -478,7 +478,7 @@ instruction variants.
 
 The `vl` register holds an unsigned integer specifying the number of
 elements to be updated with results from a vector instruction, as
-further detailed in Section <<sec-inactive-defs>>.
+further detailed in <<sec-inactive-defs>>.
 
 NOTE: The number of bits implemented in `vl` depends on the
 implementation's maximum vector length of the smallest supported
@@ -502,7 +502,7 @@ settings which require them to be saved and restored.
 
 The _XLEN_-bit-wide read-write `vstart` CSR specifies the index of the
 first element to be executed by a vector instruction, as described in
-Section <<sec-inactive-defs>>.
+<<sec-inactive-defs>>.
 
 Normally, `vstart` is only written by hardware on a trap on a vector
 instruction, with the `vstart` value representing the element on which
@@ -993,8 +993,8 @@ Masking is supported on many vector instructions.  Element operations
 that are masked off (inactive) never generate exceptions.  The
 destination vector register elements corresponding to masked-off
 elements are handled with either a mask-undisturbed or mask-agnostic
-policy depending on the setting of the `vma` bit in `vtype` (Section
-<<sec-agnostic>>).
+policy depending on the setting of the `vma` bit in `vtype`
+(<<sec-agnostic>>).
 
 The mask value used to control execution of a masked vector
 instruction is always supplied by vector register `v0`.
@@ -1017,7 +1017,7 @@ Other vector registers can be used to hold working mask values, and
 mask vector logical operations are provided to perform predicate
 calculations. [[sec-mask-vector-logical]]
 
-As specified in Section <<sec-agnostic>>, mask destination values are
+As specified in <<sec-agnostic>>, mask destination values are
 always treated as tail-agnostic, regardless of the setting of `vta`.
 
 [[sec-vector-mask-encoding]]
@@ -1489,7 +1489,7 @@ regular vector loads and stores, `nf`=0, indicating that a single
 value is moved between a vector register group and memory at each
 element position.  Larger values in the `nf` field are used to access
 multiple contiguous fields within a segment as described below in
-Section <<sec-aos>>.
+<<sec-aos>>.
 
 The `nf[2:0]` field also encodes the number of whole vector registers
 to transfer for the whole vector register load/store instructions.
@@ -2325,7 +2325,7 @@ NOTE: The floating-point widening operations were changed to `vfw*`
 from `vwf*` to be more consistent with any scalar widening
 floating-point operations that will be written as `fw*`.
 
-Widening instruction encodings must follow the constraints in Section
+Widening instruction encodings must follow the constraints in
 <<sec-vec-operands>>.
 
 [[sec-narrowing]]
@@ -2360,7 +2360,7 @@ vnop.wv  vd, vs2, vs1, vm  # integer vector-vector      vd[i] = vs2[i] op vs1[i]
 vnop.wx  vd, vs2, rs1, vm  # integer vector-scalar      vd[i] = vs2[i] op x[rs1]
 ----
 
-Narrowing instruction encodings must follow the constraints in Section
+Narrowing instruction encodings must follow the constraints in
 <<sec-vec-operands>>.
 
 [[sec-vector-integer]]
@@ -2469,7 +2469,7 @@ the second to generate the carry output (single bit encoded as a mask
 boolean).
 
 The carry inputs and outputs are represented using the mask register
-layout as described in Section <<sec-mask-register-layout>>.  Due to
+layout as described in <<sec-mask-register-layout>>.  Due to
 encoding constraints, the carry input must come from the implicit `v0`
 register, but carry outputs can be written to any vector register that
 respects the source/destination overlap restrictions.
@@ -2650,7 +2650,7 @@ pseudoinstruction is provided `vncvt.x.x.w vd,vs,vm` = `vnsrl.wx vd,vs,x0,vm`.
 The following integer compare instructions write 1 to the destination
 mask register element if the comparison evaluates to true, and 0
 otherwise.  The destination mask vector is always held in a single
-vector register, with a layout of elements as described in Section
+vector register, with a layout of elements as described in
 <<sec-mask-register-layout>>.  The destination mask vector register
 may be the same as the source vector mask register (`v0`).
 
@@ -3262,7 +3262,7 @@ The vector floating-point instructions have the same behavior as the
 scalar floating-point instructions with regard to NaNs.
 
 Scalar values for floating-point vector-scalar operations are sourced
-as described in Section <<sec-arithmetic-encoding>>.
+as described in <<sec-arithmetic-encoding>>.
 
 ==== Vector Floating-Point Exception Flags
 
@@ -3611,7 +3611,7 @@ pseudoinstruction is provided: `vfabs.v vd,vs` = `vfsgnjx.vv vd,vs,vs`.
 These vector FP compare instructions compare two source operands and
 write the comparison result to a mask register.  The destination mask
 vector is always held in a single vector register, with a layout of
-elements as described in Section <<sec-mask-register-layout>>.  The
+elements as described in <<sec-mask-register-layout>>.  The
 destination mask vector register may be the same as the source vector
 mask register (`v0`).  Compares write mask registers, and so always
 operate under a tail-agnostic policy.
@@ -4140,7 +4140,7 @@ assembler instruction alias `vpopc.m` is being retained for software
 compatibility.
 
 The source operand is a single vector register holding mask register
-values as described in Section <<sec-mask-register-layout>>.
+values as described in <<sec-mask-register-layout>>.
 
 The `vcpop.m` instruction counts the number of mask elements of the
 active elements of the vector source mask register that have the value
@@ -4554,8 +4554,8 @@ vslidedown.vi vd, vs2, uimm, vm      # vd[i] = vs2[i+uimm]
 
 For `vslidedown`, the value in `vl` specifies the maximum number of
 destination elements that are written.  The remaining elements past
-`vl` are handled according to the current tail policy (Section
-<<sec-agnostic>>).
+`vl` are handled according to the current tail policy
+(<<sec-agnostic>>).
 
 The start index (_OFFSET_) for the source can be either specified
 using an unsigned integer in the `x` register specified by `rs1`, or a
@@ -4596,8 +4596,8 @@ vector register group.
 
 The `vl` register specifies the maximum number of destination vector
 register elements updated with source values, and remaining elements
-past `vl` are handled according to the current tail policy (Section
-<<sec-agnostic>>).
+past `vl` are handled according to the current tail policy
+(<<sec-agnostic>>).
 
 
 ----
@@ -4631,8 +4631,8 @@ _i_ in the destination vector register group.
 
 The `vl` register specifies the maximum number of destination vector
 register elements written with source values, and remaining elements
-past `vl` are handled according to the current tail policy (Section
-<<sec-agnostic>>).
+past `vl` are handled according to the current tail policy
+(<<sec-agnostic>>).
 
 ----
 vslide1down.vx  vd, vs2, rs1, vm      # vd[i] = vs2[i+1], vd[vl-1]=x[rs1]
@@ -4680,7 +4680,7 @@ treated as unsigned integers.  The source vector can be read at any
 index < VLMAX regardless of `vl`.  The maximum number of elements to write to
 the destination register is given by `vl`, and the remaining elements
 past `vl` are handled according to the current tail policy
-(Section <<sec-agnostic>>).  The operation can be masked, and the mask
+(<<sec-agnostic>>).  The operation can be masked, and the mask
 undisturbed/agnostic policy is followed for inactive elements.
 
 ----
@@ -4734,8 +4734,8 @@ The vector mask register specified by `vs1` indicates which of the
 first `vl` elements of vector register group `vs2` should be extracted
 and packed into contiguous elements at the beginning of vector
 register `vd`. The remaining elements of `vd` are treated as tail
-elements according to the current tail policy (Section
-<<sec-agnostic>>).
+elements according to the current tail policy
+(<<sec-agnostic>>).
 
 ----
 Example use of vcompress instruction
@@ -5032,14 +5032,14 @@ All Zve* extensions provide support for EEW of 8, 16, and 32, and
 Zve64* extensions also support EEW of 64.
 
 All Zve* extensions support the vector configuration instructions
-(Section <<sec-vector-config>>).
+(<<sec-vector-config>>).
 
 All Zve* extensions support all vector load and store instructions
-(Section <<sec-vector-memory>>), except Zve64* extensions do not
+(<<sec-vector-memory>>), except Zve64* extensions do not
 support EEW=64 for index values when XLEN=32.
 
-All Zve* extensions support all vector integer instructions (Section
-<<sec-vector-integer>>), except that the `vmulh` integer multiply
+All Zve* extensions support all vector integer instructions
+(<<sec-vector-integer>>), except that the `vmulh` integer multiply
 variants that return the high word of the product (`vmulh.vv`,
 `vmulh.vx`, `vmulhu.vv`, `vmulhu.vx`, `vmulhsu.vv`, `vmulhsu.vx`) are
 not included for EEW=64 in Zve64*.
@@ -5055,27 +5055,27 @@ NOTE: As with `vmulh`, `vsmul` requires a large amount of additional
 logic, and 64-bit fixed-point multiplies are relatively rare.
 
 All Zve* extensions support all vector integer single-width and
-widening reduction operations (Sections <<sec-vector-integer-reduce>>,
+widening reduction operations (<<sec-vector-integer-reduce>>,
 <<sec-vector-integer-reduce-widen>>).
 
-All Zve* extensions support all vector mask instructions (Section
-<<sec-vector-mask>>).
+All Zve* extensions support all vector mask instructions
+(<<sec-vector-mask>>).
 
 All Zve* extensions support all vector permutation instructions
-(Section <<sec-vector-permute>>), except that Zve32x and Zve64x
+(<<sec-vector-permute>>), except that Zve32x and Zve64x
 do not include those with floating-point operands, and Zve64f does not include those
 with EEW=64 floating-point operands.
 
 The Zve32x extension depends on the Zicsr extension.
 The Zve32f and Zve64f extensions depend upon the F extension,
 and implement all
-vector floating-point instructions (Section <<sec-vector-float>>) for
+vector floating-point instructions (<<sec-vector-float>>) for
 floating-point operands with EEW=32. Vector single-width floating-point reduction
 operations (<<sec-vector-float-reduce>>) for EEW=32 are supported.
 
 The Zve64d extension depends upon the D extension,
 and implements all vector
-floating-point instructions (Section <<sec-vector-float>>) for
+floating-point instructions (<<sec-vector-float>>) for
 floating-point operands with EEW=32 or EEW=64 (including widening
 instructions and conversions between FP32 and FP64). Vector
 single-width floating-point reductions (<<sec-vector-float-reduce>>)
@@ -5106,31 +5106,31 @@ processed without stripmining using four vector register groups.
 The V extension supports EEW of 8, 16, and 32, and 64.
 
 The V extension supports the vector configuration instructions
-(Section <<sec-vector-config>>).
+(<<sec-vector-config>>).
 
 The V extension supports all vector load and store instructions
-(Section <<sec-vector-memory>>), except the V extension does not
+(<<sec-vector-memory>>), except the V extension does not
 support EEW=64 for index values when XLEN=32.
 
-The V extension supports all vector integer instructions (Section
-<<sec-vector-integer>>).
+The V extension supports all vector integer instructions
+(<<sec-vector-integer>>).
 
 The V extension supports all vector fixed-point arithmetic
 instructions (<<sec-vector-fixed-point>>).
 
 The V extension supports all vector integer single-width and
-widening reduction operations (Sections <<sec-vector-integer-reduce>>,
+widening reduction operations (<<sec-vector-integer-reduce>>,
 <<sec-vector-integer-reduce-widen>>).
 
-The V extension supports all vector mask instructions (Section
-<<sec-vector-mask>>).
+The V extension supports all vector mask instructions
+(<<sec-vector-mask>>).
 
-The V extension supports all vector permutation instructions (Section
-<<sec-vector-permute>>).
+The V extension supports all vector permutation instructions
+(<<sec-vector-permute>>).
 
 The V extension depends upon the F and D
 extensions, and implements all vector floating-point instructions
-(Section <<sec-vector-float>>) for floating-point operands with EEW=32
+(<<sec-vector-float>>) for floating-point operands with EEW=32
 or EEW=64 (including widening instructions and conversions between
 FP32 and FP64). Vector single-width floating-point reductions
 (<<sec-vector-float-reduce>>) for EEW=32 and EEW=64 are supported as
@@ -5159,7 +5159,7 @@ The Zvfhmin extension depends on the Zve32f extension.
 
 The Zvfh extension provides support for vectors of IEEE 754-2008
 binary16 values.
-When the Zvfh extension is implemented, all instructions in Sections
+When the Zvfh extension is implemented, all instructions in
 <<sec-vector-float>>, <<sec-vector-float-reduce>>,
 <<sec-vector-float-reduce-widen>>, <<sec-vector-float-move>>,
 <<sec-vfslide1up>>, and <<sec-vfslide1down>>