(no commit message)

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 434d87bdff9859475321390c3736e9c8815f349c..762d6877d42f8e63fa852db8e18f40924c9769fa 100644 (file)
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -68,7 +68,7 @@ which is a different convention from that used elsewhere in the Power ISA.
 The SVP64 prefix always comes before the suffix in PC order and must be
 considered an independent "Defined word" that augments the behaviour of
 the following instruction, but does **not** change the actual Decoding
-of that following instruction.  **All prefixed 32-bit instructions
+of that following instruction.  **All SVP64-prefixed 32-bit instructions
 (Defined Words) retain their non-prefixed encoding and definition**.
 
 Two apparent exceptions to the above hard rule exist: SV
@@ -136,21 +136,49 @@ require a trap if reserved fields are nonzero, instead relying on software
 to avoid use of such fields.  Where the standard Power
 ISA definition is intended the red keyword `RESERVED` is used.
 
-##  Definition of "UnVectoriseable"
+## Definition of "PO9-Prefixed"
 
-Any operation that inherently makes no sense if repeated is termed
-"UnVectoriseable" or "UnVectorised".  Examples include `sc` or `sync`
-which have no registers. `mtmsr` is also classed as UnVectoriseable
+Used in the context of "A PO9-Prefixed Word" this is a new area similar to EXT100-163
+that is shared between SVP64-Single, SVP64, 32 Vectorizable new Opcode areas
+EXT200-231, one RESERVED 57-bit future Opcode space, and three new Unvectorizable
+RESERVED 32-bit future Opcode spaces. See [[sv/po9_encoding]].
+
+## Definition of "SVP64-Prefix"
+
+A 24-bit RISC-Paradigm Encoding area for Loop-Augmentation of the following
+"Defined word-instruvtion".
+Used in the context of "An SVP64-Prefixed Defined Word-instruction", as separate and
+distinct from the 32-bit PO9-Prefix that holds a 24-bit SVP64 Prefix.
+
+##  Definition of "Vectorizable" and "Unvectorizable"
+
+"Vectorizable" Defined Word-instructions are Scalar instructions that
+benefit from SVP64 Loop-Prefixing.
+Conversely, any operation that inherently makes no sense if repeated in a
+Vector Loop is termed
+"Unvectorizable" or "Unvectorized".  Examples include `sc` or `sync`
+which have no registers. `mtmsr` is also classed as Unvectorizable
 because there is only one `MSR`.
 
-UnVectorised instructions are required to be detected as such if
+UnVectorized instructions are required to be detected as such if
 Prefixed (either SVP64 or SVP64Single) and an Illegal Instruction
 Trap raised.
 
 *Architectural Note: Given that a "pre-classification" Decode Phase is
 required (identifying whether the Suffix - Defined Word - is
 Arithmetic/Logical, CR-op, Load/Store or Branch-Conditional),
-adding "UnVectorised" to this phase is not unreasonable.*
+adding "Unvectorised" to this phase is not unreasonable.*
+
+Vectorizable Defined Word-instructions are **required** to be Vectorized,
+or they may not be permitted to be added at all to the Power ISA as Defined
+Word-instructions.
+
+*Engineering note: implementations may not choose to add Defined Word-instructions
+without also adding hardware support for SVP64-Prefixing of the same.*
+
+*ISA Working Group note: Vectorized PackedSIMD instructions if ever proposed
+should be considered Unvectorizable and except in extreme mitigating circumstances
+rejected outright.*
 
 ## Definition of Strict Program Order