From c18ba0545e77a1337863f62a207150adaf7ac0e6 Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 29 Mar 2023 17:45:42 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls010.mdwn | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) 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 -- 2.30.2