From: lkcl Date: Sun, 3 Apr 2022 15:17:08 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2897 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=6ec2d73db58e670dfc21c2b4d8dc15f8471ba80e;p=libreriscv.git --- diff --git a/openpower/sv/normal.mdwn b/openpower/sv/normal.mdwn index 16f8d4c0d..e20d410ac 100644 --- a/openpower/sv/normal.mdwn +++ b/openpower/sv/normal.mdwn @@ -95,10 +95,11 @@ the hugely detrimental effect it has on parallel processing, XER.SO is overflow bit is therefore simply set to zero if saturation did not occur, and to one if it did. -Note also that saturate on operations that set OE=1 are -`UNDEFINED` due to the conflicting use of the CR.so bit for storing if +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, CA32): -these two bits will also be `UNDEFINED` if saturation is requested. +these two bits will be `UNDEFINED` if saturation is also requested. Post-analysis of the Vector of CRs to find out if any given element hit saturation may be done using a mapreduced CR op (cror), or by using the @@ -125,7 +126,6 @@ the other for arithmetic operations (actually, CR-driven). Note in each case the assumption is that vector elements are required appear to be executed in sequential Program Order, element 0 being the first. - * Data-driven (CR-driven) fail-on-first activates when Rc=1 or other CR-creating operation produces a result (including cmp). Similar to branch, an analysis of the CR is performed and if the test fails, the