(no commit message)

diff --git a/openpower/sv/normal.mdwn b/openpower/sv/normal.mdwn
index 16f8d4c0deb30490cb8a6a277741beff0e22dbc1..e20d410aced66f4d6cdcf16bdb1aa18b1d17abb5 100644 (file)
--- 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