From 45d36a5dd58ac3ef381c140f4caef47696b5b0ad Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 2 Jun 2022 15:29:27 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) 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 -- 2.30.2