From 463c4f3ffc0a1ac21ed659291cd570aebb0e9d03 Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 9 Jun 2022 16:56:07 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index b46b83bfb..9b0e66782 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -12,11 +12,15 @@ SVP64 is designed around these fundamental and inviolate RISC principles: with scalar instructions (the suffix) How can a Vector ISA even exist when no actual Vector instructions -are permitted to be added? It comes down to the strict abstraction. -First you add a **scalar** instruction (32-bit). Second, the +are permitted to be added? It comes down to the strict RISC abstraction. +First you start from a **scalar** instruction (32-bit). Second, the Prefixing is applied *in the abstract* to give the *appearance* and ultimately the same effect as if an explicit Vector instruction -had also been added. +had also been added. Looking at the pseudocode of any Vector ISA +(RVV, NEC SX Aurora, Cray) +they always comprise (a) a for-loop around (b) element-based operations. +It is perfectly reasonable and rational to separate (a) from (b) +and find a powerful Supercomputing-class ISA that qualifies for (b). There are a few exceptional places where these rules get bent, and others where the rules take some explaining, @@ -256,7 +260,7 @@ The underlying key to understanding: # CR weird instructions -[[openpower/sv/int_cr_predication]] is by far the biggest violator of the SVP64 +[[sv/cr_int_predication]] is by far the biggest violator of the SVP64 rules, for good reasons. Transfers between Vectors of CR Fields and Integers for use as predicates is very awkward without them. -- 2.30.2