From: lkcl <lkcl@web>
Date: Thu, 2 Jun 2022 14:29:27 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~2014
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=45d36a5dd58ac3ef381c140f4caef47696b5b0ad;p=libreriscv.git

---

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 45e325dd7..a333a4a51 100644
--- 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