From 0cec55bd6cef70100c504deb152463925a1e385c Mon Sep 17 00:00:00 2001
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Fri, 7 Apr 2023 00:21:02 +0100
Subject: [PATCH] move PO9-encoding to ls001

---
 openpower/sv/po9_encoding.mdwn | 30 ++++++++++++++++++++++++++----
 openpower/sv/rfc/ls001.mdwn    |  3 +++
 openpower/sv/rfc/ls010.mdwn    |  1 -
 3 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn
index 9714d695c..21d310dcb 100644
--- a/openpower/sv/po9_encoding.mdwn
+++ b/openpower/sv/po9_encoding.mdwn
@@ -1,5 +1,27 @@
+# Definitions
+
+**Proposal: Add the following Definition to Section 1.3.1 of Book I**
+
+Definition of "UnVectoriseable":
+
+Any operation that inherently makes no sense if repeated (through SVP64
+Prefixing) is termed "UnVectoriseable" or "UnVectorised".  Examples
+include `sc` or `sync` which have no registers. `mtmsr` is also classed
+as UnVectoriseable because there is only one `MSR`.
+
+UnVectorised 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.*
+
 # New 64-bit Instruction Encoding spaces
 
+**Proposal: Add new Section 1.6.5 to Book I**
+
 The following seven new areas are defined within Primary Opcode 9 (EXT009)
 as a new 64-bit encoding space, alongside Primary Opcode 1
 (EXT1xx).
@@ -25,11 +47,11 @@ areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
 they may equally be allocated entirely differently.
 
 *Architectural Resource Allocation Note: **under no circumstances** must
-different Defined Words be allocated within any `EXT{z}` prefixed
-or unprefixed space for a given value of `z`. Even if UnVectoriseable
+different Defined Words be allocated within any `EXT{z}` prefixed or
+unprefixed space for a given value of `z` of 0, 2 or 3. Even if UnVectoriseable
 an instruction Defined Word space must have the exact same Instruction
-and exact same Instruction Encoding in all spaces being RESERVED - Illegal
-Instruction Trap - if UnVectoriseable) or not be allocated at all.
+and exact same Instruction Encoding in all spaces being RESERVED (Illegal
+Instruction Trap if UnVectoriseable) or not be allocated at all.
 This is required as an inviolate hard rule governing Primary Opcode 9
 that may not be revoked under any circumstances. A useful way to think
 of this is that the Prefix Encoding is, like the 8086 REP instruction,
diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index dbf137b72..67ac35117 100644
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -874,6 +874,9 @@ on their merits.
 
 \newpage{}
 
+[[!inline pages="openpower/sv/po9_encoding" raw=yes ]]
+
+
 **EXT000-EXT063**
 
 These are Scalar word-encodings. Often termed "v3.0 Scalar" in this document
diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index 1e53be0ca..5e4497ba2 100644
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -98,5 +98,4 @@ Add the following entries to:
 [[!inline pages="openpower/sv/normal" raw=yes ]]
 [[!inline pages="openpower/sv/ldst" raw=yes ]]
 [[!inline pages="openpower/sv/branches" raw=yes ]]
-[[!inline pages="openpower/sv/po9_encoding" raw=yes ]]
 [[!inline pages="openpower/sv/cr_ops" raw=yes ]]
-- 
2.30.2