From: lkcl <lkcl@web>
Date: Wed, 29 Mar 2023 16:45:42 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls012_v1~241
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=c18ba0545e77a1337863f62a207150adaf7ac0e6;p=libreriscv.git

---

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index c67f09f26..8363a1422 100644
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -888,11 +888,13 @@ element, to indicate whether saturation occurred.  Note that due to
 the hugely detrimental effect it has on parallel processing, XER.SO is
 **ignored** completely and is **not** brought into play here.  The CR
 overflow bit is therefore simply set to zero if saturation did not occur,
-and to one if it did.
+and to one if it did.  This behaviour (ignoring XER.SO) is actually optional in
+the SFFS Compliancy Subset: for SVP64 it is made mandatory *but only on
+Vectorised instructions*.
 
 Note also that saturate on operations that set OE=1 must raise an Illegal
 Instruction due to the conflicting use of the CR.so bit for storing if
-saturation occurred. Integer Operations that produce a Carry-Out (CA,
+saturation occurred. Vectorised Integer Operations that produce a Carry-Out (CA,
 CA32): these two bits will be `UNDEFINED` if saturation is also requested.
 
 Note that the operation takes place at the maximum bitwidth (max of
@@ -903,7 +905,10 @@ dest elwidth.
 given element hit saturation may be done using a mapreduced CR op (cror),
 or by using the new crrweird instruction with Rc=1, which will transfer
 the required CR bits to a scalar integer and update CR0, which will allow
-testing the scalar integer for nonzero.  see [[sv/cr_int_predication]]*
+testing the scalar integer for nonzero.  see [[sv/cr_int_predication]].
+Alternatively, a Data-Dependent Fail-First may be used to truncate the
+Vector Length to non-saturated elements, greatly increasing the productivity
+of parallelised inner hot-loops.*
 
 ## Reduce mode