(no commit message)

[libreriscv.git] / openpower / sv / cr_ops.mdwn

diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn
index 84390476e081912ef79520fd2c9a7fcff735f823..e9d0b45a3687ececc0678d5556f4a17ea0346595 100644 (file)
--- a/openpower/sv/cr_ops.mdwn
+++ b/openpower/sv/cr_ops.mdwn
@@ -6,6 +6,7 @@ Links:
 
 * <https://bugs.libre-soc.org/show_bug.cgi?id=687>
 * <https://bugs.libre-soc.org/show_bug.cgi?id=936> write on failfirst
+* <https://bugs.libre-soc.org/show_bug.cgi?id=1183> enable mapreduce with failfirst
 * [[svp64]]
 * [[sv/branches]]
 * [[sv/cr_int_predication]]
@@ -17,8 +18,8 @@ Condition Register Fields are only 4 bits wide: this presents some
 interesting conceptual challenges for SVP64, which was designed
 primarily for vectors of arithmetic and logical operations. However
 if predicates may be bits of CR Fields it makes sense to extend
-Simple-V to cover CR Operations, especially given that Vectorised Rc=1
-may be processed by Vectorised CR Operations that usefully in turn
+Simple-V to cover CR Operations, especially given that Vectorized Rc=1
+may be processed by Vectorized CR Operations that usefully in turn
 may become Predicate Masks to yet more Vector operations, like so:
 
 ```
@@ -44,7 +45,7 @@ considered to be a "co-result". Such CR Field "co-result" arithmeric
 operations are firmly out of scope for this section, being covered fully
 by [[sv/normal]].
 
-* Examples of Vectoriseable Defined Words to which this section does
+* Examples of Vectorizeable Defined Word-instructions to which this section does
   apply is
   - `mfcr` and `cmpi` (3 bit operands) and
   - `crnor` and `crand` (5 bit operands).
@@ -93,7 +94,6 @@ Fields:
   a CR bit and whether it is set (inv=0) or unset (inv=1)
 * **RG** Reverse-Gear: inverts the Vector Loop order (VL-1 downto 0) rather
   than the normal 0 upto VL-1
-* **SVM** sets "subvector" reduce mode
 * **VLi** VL inclusive: in fail-first mode, the truncation of
   VL *includes* the current element at the failure point rather
   than excludes it from the count.
@@ -108,7 +108,7 @@ Register Field generated from Rc=1 is used as the basis for the truncation
 decision.  However with CR-based operations that CR Field result to be
 tested is provided *by the operation itself*.
 
-Data-dependent SVP64 Vectorised Operations involving the creation
+Data-dependent SVP64 Vectorized Operations involving the creation
 or modification of a CR can require an extra two bits, which are not
 available in the compact space of the SVP64 RM `MODE` Field. With the
 concept of element width overrides being meaningless for CR Fields it
@@ -176,11 +176,9 @@ operations), and ignoring the Rc=1 co-results entirely,
 the totals (the behaviours) are consistent whether
 VLi=0 or VLi=1.
 
-*Programmer's Note: if necessary VL may be obtained by using the alias
-`getvl`, followed by incrementing or decrementing the GPR with the
-copy of VL, and using `setvl` with the same GPR, to adjust VL.
-Programmers should be aware that MAXVL will always limit
-VL*.
+*Programmer's Note: Data-dependent fail-first stores an updated
+VL in the SVSTATE SPR, not in any GPR. If needed
+VL may be obtained by using the alias `getvl`.
 
 ## Reduction and Iteration
 
@@ -268,13 +266,13 @@ Adding entirely new pipelines and a new Vector CR Register file
 is a much easier proposition to consider.
 
 The prohibitions utilise the CR Field numbers implicitly to
-split out Vectorised CR operations to be considered completely
+split out Vectorized CR operations to be considered completely
 separare and distinct from Scalar CR operations *even though
 they both use the same binary encoding*.  This does in turn
 mean that at the Decode Phase it becomes necessary to examine
 not only the operation (`sv.crand`, `sv.cmp`) but also
 the CR Field numbers as well as whether, in the EXTRA2/3 Mode
-bits, the operands are Vectorised.
+bits, the operands are Vectorized.
 
 A future version of Power ISA, where SVP64Single is proposed,
 would in fact introduce "Conditional Execution", including