(no commit message)

diff --git a/openpower/sv/svp_rewrite/svp64.mdwn b/openpower/sv/svp_rewrite/svp64.mdwn
index 8512debddacfb33c438fac23cc286e4d1f5164bb..554ef4eb512e46f2e212a8c34ef0e3bd721ca2ae 100644 (file)
--- a/openpower/sv/svp_rewrite/svp64.mdwn
+++ b/openpower/sv/svp_rewrite/svp64.mdwn
@@ -40,21 +40,6 @@ v3.0/1B instructions covered by the prefix are "unaltered". This is termed `scal
 Note that this is completely different from when VL=0.  VL=0 turns all operations under its influence into `nops` (regardless of the prefix)
  whereas when VL=1 and the SV prefix is all zeros, the operation simply acts as if SV had not been applied at all to the instruction  (an "identity operation").
 
-# XER, SO and other global flags
-
-Vector systems are expected to be high performance.  This is achieved
-through parallelism, which requires that elements in the vector be
-independent.  XER SO and other global "accumulation" flags (CR.OV) cause
-Read-Write Hazards on single-bit global resources, having a significant
-detrimental adverse effect.
-
-Consequently in SV, XER.SO and CR.OV behaviour is disregarded.  XER is
-simply neither read nor written.  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.
-
-An interesting side-effect of this decision is that the OE flag is now free for other uses when SV Prefixing is used.
-
-Regarding XER.CA: this does not fit either: it was designed for a sxalar ISA. Instead, both carry-in and carry-out go into the CR.so bit of a given Vector element.
-
 
 
 # Register Naming and size
@@ -504,6 +489,21 @@ but select different *bits* of the same CRs
 
 # Appendix
 
+## XER, SO and other global flags
+
+Vector systems are expected to be high performance.  This is achieved
+through parallelism, which requires that elements in the vector be
+independent.  XER SO and other global "accumulation" flags (CR.OV) cause
+Read-Write Hazards on single-bit global resources, having a significant
+detrimental adverse effect.
+
+Consequently in SV, XER.SO and CR.OV behaviour is disregarded.  XER is
+simply neither read nor written.  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.
+
+An interesting side-effect of this decision is that the OE flag is now free for other uses when SV Prefixing is used.
+
+Regarding XER.CA: this does not fit either: it was designed for a scalar ISA. Instead, both carry-in and carry-out go into the CR.so bit of a given Vector element.  This provides a means to perform large parallel batches of Vectorised carry-capable additions.
+
 ## v3.0B/v3.1B relevant instructions
 
 SV is primarily designed for use as an efficient hybrid 3D GPU / VPU / CPU ISA.