In essence it becomes the programmer's responsibility to leverage the
 pre-determined schedules to desired effect.
 
-## Scalar result reduce mode
+## Scalar result reduction and iteration
 
 Scalar Reduction per se does not exist, instead is implemented in SVP64
 as a simple and natural relaxation of the usual restriction on the Vector
 provided.
 
 In this mode, which is suited to operations involving carry or overflow,
-one register must be identified by the programmer as being the "accumulator".
-Scalar reduction is thus categorised by:
+one register must be assigned, by convention by the programmer to be the
+"accumulator".  Scalar reduction is thus categorised by:
 
 * One of the sources is a Vector
 * the destination is a scalar
   also the scalar destination (which may be informally termed
   the "accumulator")
 * That the source register type is the same as the destination register
-  type identified as the "accumulator".  scalar reduction on `cmp`,
+  type identified as the "accumulator".  Scalar reduction on `cmp`,
   `setb` or `isel` makes no sense for example because of the mixture
   between CRs and GPRs.
 
      for i in range(VL):
           iregs[RA] += iregs[RB+i] # RT==RA
 
-However, *unless* the operation is marked as "mapreduce", SV ordinarily
+However, *unless* the operation is marked as "mapreduce" (`sv.add/mr`)
+SV ordinarily
 **terminates** at the first scalar operation.  Only by marking the
 operation as "mapreduce" will it continue to issue multiple sub-looped
 (element) instructions in `Program Order`.