From: lkcl <lkcl@web>
Date: Sun, 21 Aug 2022 21:05:51 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~795
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=92f40ea135122da6f6270db9457e2da75a4646ff;p=libreriscv.git

---

diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn
index c5899e5fe..ddb408e33 100644
--- a/openpower/sv/cr_ops.mdwn
+++ b/openpower/sv/cr_ops.mdwn
@@ -95,7 +95,7 @@ Fields:
 * **zz** set both sz and dz equal to this flag
 * **SNZ** when sz=1 and SNZ=1 a value "1" is put in place of zeros when
   the predicate bit is clear (on both source and destination masks)
-* **inv CR bit** just as in branches (BO) these bits allow testing of a CR bit and whether it is set (inv=0) or unset (inv=1)
+* **inv CR-bit** just as in branches (BO) these bits allow testing of a CR bit and whether it is set (inv=0) or unset (inv=1)
 * **RG** inverts the Vector Loop order (VL-1 downto 0) rather
 than the normal 0..VL-1
 * **SVM** sets "subvector" reduce mode
@@ -108,7 +108,7 @@ than the normal 0..VL-1
 The principle of data-dependent fail-first is that if, during
 the course of sequentially evaluating an element's Condition Test,
 one such test is encountered which fails,
-then VL (Vector Length) is truncated at that point. In the case
+then VL (Vector Length) is truncated (set) at that point. In the case
 of Arithmetic SVP64 Operations the Condition 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
@@ -167,7 +167,7 @@ Just as with SVP64 [[sv/branches]] there is the option to truncate
 VL to include the element being tested (`VLi=1`) and to exclude it
 (`VLi=0`).
 
-Also just as with [[sv/normal]] fail-first VL cannot, unlike
+Also exactly as with [[sv/normal]] fail-first, VL cannot, unlike
 [[sv/ldst]], be set to an arbitrary value.  Deterministic behaviour
 is *required*.
 
@@ -179,7 +179,7 @@ the same rules apply to CR Operations, i.e. that programmers must
 follow certain conventions in order for an *end result* of a
 reduction to be achieved.  Unlike
 other Vector ISAs *there are no explicit reduction opcodes*
-in SVP64.
+in SVP64: Schedules however achieve the same effect.
 
 Due to these conventions only reduction on operations such as `crand`
 and `cror` are meaningful because these have Condition Register Fields
@@ -207,6 +207,10 @@ for example, although there are many ways in which the same calculation
 could be carried out after transferring a vector of CR Fields to a GPR
 using crweird operations.
 
+Implementations are free and clear to optimise these reductions in any
+way they see fit, as long as the end-result is compatible with Strict Program
+Order being observed, and Interrupt latency is not adversely impacted.
+
 # LD/ST Pack/Unpack Mode
 
 As described in [[sv/normal]],