(no commit message)

diff --git a/openpower/sv/biginteger/analysis.mdwn b/openpower/sv/biginteger/analysis.mdwn
index 518912630b7bd4f93e6e57ad1cbcef39c701525a..8c30e2e9c65f1a27fa84455133de9f79dee90b97 100644 (file)
--- a/openpower/sv/biginteger/analysis.mdwn
+++ b/openpower/sv/biginteger/analysis.mdwn
@@ -37,13 +37,18 @@ This pattern - sequential execution of individual instructions
 with incrementing register numbers - is precisely the very definition
 of how SVP64 works!
 Thus, due to sequential execution of `adde` both consuming and producing
-a CA Flag, `sv.adde` is in effect an alias for Vectorised add.  As such,
+a CA Flag, with no additions to SVP64 or to the v3.0 Power ISA,
+`sv.adde` is in effect an alias for Big-Integer Vectorised add.  As such,
 implementors are entirely at liberty to recognise Horizontal-First Vector
 adds and send the vector of registers to a much larger and wider back-end
-ALU, and/or short-cut the intermediate storage of XER.CA on an element
-level and implement a Vector-aware carry propagation algorithm
-in back-end hardware that need only read the first incoming XER.CA and
-only store the last XER.CA. The size of the underlying back-end SIMD ALU
+ALU, and short-cut the intermediate storage of XER.CA on an element
+level in back-end hardware that need only:
+
+* read the first incoming XER.CA
+* implement a Vector-aware carry propagation algorithm
+* store the very last XER.CA in the batch
+
+The size and implementation of the underlying back-end SIMD ALU
 is entirely at the discretion of the implementer.
 
 If there is pressure on the register file (or