add potential opcode solution to rfc ls001

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 236494cc46588a8c7a12b74d465dd2bae515ba4f..c0240d57cd14305b563d44a5a1e6bc2bca1fbdbf 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -274,6 +274,72 @@ For each of EXT059 and EXT063:
   [under evaluation](https://bugs.libre-soc.org/show_bug.cgi?id=923)
   as of 08Sep2022
 
+\newpage{}
+# Potential Opcode allocation
+
+There are unfortunately some inviolate requirements that directly place
+pressure on the EXT000-EXT063 (32-bit) opcode space to such a degree that
+it risks jeapordising the Power ISA. These requirements are:
+
+* all of the scalar operations must be Vectoriseable
+* all of the scalar operations intended for Vectorisation
+  must be in a 32-bit encoding (not prefixed-prefixed to 96-bit)
+* bringing Scalar Power ISA up-to-date from the past 12 years
+  needs 75% of two Major opcodes all on its own
+
+There exists a potential scheme which meets (exceeds) the above criteria,
+providing plenty of room for both Scalar (and Vectorised) operations,
+*and* provides SVP64-Single with the same amount of room to grow.  It
+is based loosely around the existing Public v3.1 EXT001 Encoding
+Scheme.
+
+| 0-5 | 6 | 7 | 8-31  | Description               |
+|-----|---|---|-------|---------------------------|
+| PO  | 0 | 0 | 0000  | `RESERVED1`               |
+| PO  | 0 | 0 | !zero | new-suffix, scalar (SVP64Single) |
+| PO  | 1 | 0 | 0000  | `RESERVED2`               |
+| PO  | 1 | 0 | !zero | old-suffix, scalar (SVP64Single) |
+| PO  | 0 | 1 | nnnn  | new-suffix, vector (SVP64)       |
+| PO  | 1 | 1 | nnnn  | old-suffix, vector (SVP64)       |
+
+The above table requires some explanation, with some definitions.
+
+* **PO** - Primary Opcode. Likely candidates: EXT022, EXT005, EXT009
+* **bit 6** - specifies whether the suffix is old (EXT000-EXT063)
+  or new (EXTn00-EXTn63, n greater than 1)
+* **bit 7** - defines whether the Suffix is Scalar-Prefixed or Vector-Prefixed
+  (caveat: see bits 8-31)
+* **old-suffix** - the EXT000 to EXT063 32-bit Major opcodes of Power ISA 3.0
+* **new-suffix** - two **new** Major Opcode areas **exclusively**
+  for Scalar-only instructions that shall **never** be Prefixed by SVP64:
+  RESERVED1 EXT200-EXT263 and
+  RESERVED2 EXT300-EXT363
+* **0000** - all 24 bits bits 8-31 are zero (0x000000)
+* **!zero** - bits 8-31 may be any value *other* than zero
+* **nnnn** - bits 8-31 may be any value in the range 0x000000 to 0xffffff
+* **SVP64Single** - a (TBD) Encoding that is near-identical to SVP64
+  except that it is not a Vector Operation (equivalent to hard-coded VL=1
+  at all times). Predication is permitted, Element-width-overrides is
+  permitted, Saturation is permitted. SVP64Single is a **scalar** augmentation
+  of its suffix.
+* **SVP64** - a (well-defined, 2 years) DRAFT Proposal for a Vectorisation
+  Augmentation of suffixes.
+
+(*For completeness, we recall that EXT100 to EXT163 is the numbering for
+Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which,
+in Section 1.6.3, we note that bit 6 is set to 1.  This concept is where
+the above scheme originated. Section 1.6.3 uses the term "defined word"
+to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed
+to create the new numbering EXT100-EXT163, respectively*)
+
+The opportunity to create two new 32-bit encoding spaces each with
+64 Major opcodes each is best made with another table:
+
+|          | Scalar (bit7=0,8-31=0000) | Scalar (bit7=0,8-31=!zero)| Vector (bit7=1)  |
+|----------|---------------------------|---------------------------|------------------|
+|new bit6=0| `RESERVED1`:{EXT200-063}  | SVP64-Single:{EXT200-263} | SVP64:{EXT200-263} |
+|old bit6=1| `RESERVED2`:{EXT300-363}  | SVP64-Single:{EXT000-063}   | SVP64:{EXT000-063}   |
+
 \newpage{}
 # Use cases