(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index b46b83bfba41023d19c86ffe50de94fa50c671a9..9b0e6678245a39f915d32317612a135a30f94657 100644 (file)
--- 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.