(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 45e325dd7a590dc9d45e7eac93f47b3d5720ad53..a333a4a516abfff60218ca256d1ded67414bf0f1 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -106,7 +106,7 @@ which simply make no sense in a RISC Scalar ISA: element-stride and
 unit-stride and the entire concept of a stride itself (a spacing
 between elements) has no place at all in a Scalar ISA. The problems
 come when trying to *retrofit* the concept of "Vector Elements" onto
-a Scalar ISA, and it required a couple of bits (Modes) in the SVP64
+a Scalar ISA. Consequently it required a couple of bits (Modes) in the SVP64
 RM Prefix to convey the stride mode, changing the Effective Address
 computation as a result. Interestingly, worth noting for Hardware
 designers: it did turn out to be possible to perform pre-multiplication
@@ -140,6 +140,15 @@ Again this comes down to being quite strict about the rules: only Scalar
 instructions get Vectorised: there are *no* actual explicit Vector
 instructions.
 
+**Summary**
+
+Where a traditional Vector ISA effectively duplicates the entirety
+of a Scalar ISA and then adds additional instructions which only
+make sense in a Vector Context, such as Vector Shuffle, SVP64 goes to
+considerable lengths to keep strictly to augmentation and embedding
+of an entire Scalar ISA's instructions into an abstract Vectorisation
+Context.
+
 # CR weird instructions
 
 [[sv/int_cr_predication]] is by far the biggest violator of the SVP64