(no commit message)

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index c67f09f26933684271e982abfded1ac734f8ee95..8363a14220d718798e16e8665a57e87c09a21fcb 100644 (file)
--- 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