(no commit message)

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index 97cbd5d639e396e0a345920584a98eb7333d3332..1e14c7748e1605e5dfe63051a60974c9253697d4 100644 (file)
--- a/openpower/sv/svp64/appendix.mdwn
+++ b/openpower/sv/svp64/appendix.mdwn
@@ -21,8 +21,10 @@ independent.  XER SO/OV and other global "accumulation" flags (CR.SO) cause
 Read-Write Hazards on single-bit global resources, having a significant
 detrimental effect.
 
-Consequently in SV, XER.SO and OV behaviour is disregarded (including
-in `cmp` instructions).  XER is simply neither read nor written.
+Consequently in SV, XER.SO behaviour is disregarded (including
+in `cmp` instructions).  XER.SO is not read, but XER.OV may be written,
+breaking the Read-Modify-Write Hazard Chain that complicates
+microarchitectural implementations.
 This includes when `scalar identity behaviour` occurs.  If precise
 OpenPOWER v3.0/1 scalar behaviour is desired then OpenPOWER v3.0/1
 instructions should be used without an SV Prefix.
@@ -31,13 +33,9 @@ TODO jacob add about OV https://www.intel.com/content/dam/www/public/us/en/docum
 
 Of note here is that XER.SO and OV may already be disregarded in the
 Power ISA v3.0/1 SFFS (Scalar Fixed and Floating) Compliancy Subset.
-SVP64 simply makes it mandatory to disregard even for other Subsets,
+SVP64 simply makes it mandatory to disregard XER.SO even for other Subsets,
 but only for SVP64 Prefixed Operations.
 
-An interesting side-effect of this decision is that the OE flag is now
-free for other uses when SV Prefixing is used, and CR.SO may likewise
-used for other purposes (saturation for example).
-
 XER.CA/CA32 on the other hand is expected and required to be implemented
 according to standard Power ISA Scalar behaviour.  Interestingly, due
 to SVP64 being in effect a hardware for-loop around Scalar instructions