(no commit message)

[libreriscv.git] / openpower / sv / po9_encoding.mdwn

diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn
index ec7f90244fa15122f74cf7755a65066b6b778681..7d041c06bacb4b86edb095bb64a2cd590325e4ed 100644 (file)
--- a/openpower/sv/po9_encoding.mdwn
+++ b/openpower/sv/po9_encoding.mdwn
@@ -46,7 +46,7 @@ files horizontally, where moving to the next instruction is a clear priority.
 A 32-bit Prefix in front of a Defined Word that extends register
 numbers (allows larger register files), adds single-bit predication,
 element-width overrides, and optionally adds Saturation to Arithmetic
-instructions that normally would not have it.  *SVP64 is in Draft only*
+instructions that normally would not have it.  *SVP64Single is in Draft only*
 and is yet to be defined.
 
 **Definition of "UnVectoriseable":**
@@ -59,7 +59,7 @@ 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
+*Hardware 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.*
@@ -72,21 +72,29 @@ The following seven new areas are defined within Primary Opcode 9 (EXT009)
 as a new 64-bit encoding space, alongside Primary Opcode 1
 (EXT1xx).
 
-| 0-5 | 6 | 7 | 8-31  | 32| Description                        |
-|-----|---|---|-------|---|------------------------------------|
-| PO  | 0 | x | xxxx  | 0 | `RESERVED2` (57-bit) |
-| PO  | 0 | 0 | !zero | 1 | SVP64Single:EXT232-263, or `RESERVED3` |
-| PO  | 0 | 0 | 0000  | 1 | Scalar EXT232-263               |
-| PO  | 0 | 1 | nnnn  | 1 | SVP64:EXT232-263     |
-| PO  | 1 | 0 | 0000  | x | `RESERVED1` (32-bit) |
-| PO  | 1 | 0 | !zero | n | SVP64Single:EXT000-063 or `RESERVED4` |
-| PO  | 1 | 1 | nnnn  | n | SVP64:EXT000-063       |
+| 0-5 | 6 | 7 | 8-31  | 32|33-63|Description                        |
+|-----|---|---|-------|---|-----|-----------------------------------|
+| PO9 | 0 | x | xxxx  | 0 | xxxx|  `RESERVED2` (57-bit) |
+| PO9 | 0 | 0 | !zero | 1 | DWd | SVP64Single:EXT232-263, or `RESERVED3` |
+| PO9 | 0 | 0 | 0000  | 1 | DWd | Scalar EXT232-263               |
+| PO9 | 0 | 1 | nnnn  | 1 | DWd | SVP64:EXT232-263     |
+| PO9 | 1 | 0 | 0000  | x | xxxx| `RESERVED1` (32-bit) |
+| PO9 | 1 | 0 | !zero | n | DWd | SVP64Single:EXT000-063 or `RESERVED4` |
+| PO9 | 1 | 1 | nnnn  | n | DWd | SVP64:EXT000-063       |
+
+Key:
+
+* **x** - a `RESERVED` encoding. Illegal Instruction Trap must be raised
+* **n** - a specification-defined value
+* **!zero** - a non-zero specification-defined value
+* **DWd** - when including bit 32 is a "Defined Word" as explained in
+  Book I Section 1.6 (Public v3.1 p11)
 
 Note that for the future SVP64Single Encoding (currently RESERVED3 and 4)
 it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
 for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
 prohibition allows SVP64Single to share its Encoding space with Scalar
-Ext232-263 and Scalar EXT300-363.
+EXT232-263 and Scalar EXT300-363.
 
 Also that RESERVED1 and 2 are candidates for future Major opcode
 areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
@@ -116,11 +124,19 @@ Encoding spaces and their potential are illustrated:
 
 Notes:
 
-* Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
+* **PO9**-PO1 Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
   thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
   on top of an SVP64 prefix which is 32-bit on top of a Defined Word
   and the complexity at the Decoder becomes too great for High
   Performance Multi-Issue systems.
+* There is however no reason why PO9-PO1 (EXT901?) as an entirely new RESERVED
+  64-bit Encoding
+  should not be permitted as long as it is clearly marked as UnVectoriseable.
+* PO1-**PO9** Prefixed-Prefixed (96-bit) instructions are also prohibited
+  for the same reason: Multi-Issue Decode complexity is too great.
+* There is however no reason why PO1-PO9 (EXT109) as an entirely new RESERVED
+  64-bit Encoding
+  should not be permitted as long as it is clearly marked as UnVectoriseable.
 * EXT100-163 instructions (PO1-Prefixed) are also prohibited from being
   double-PO1-prefixed (not twice prefixed)
 * RESERVED2 presently remains unallocated as of yet and therefore its
@@ -129,7 +145,10 @@ Notes:
   that the area is UnVectoriseable and also cannot be Prefixed with
   SVP64Single.
 * Considerable care is needed both on Architectural Resource Allocation
-  as well as instruction design itself.  Once an instruction is allocated
+  as well as instruction design itself. All new Scalar instructions automatically
+  and inherently must be designed taking their Vectoriseable potential into
+  consideration *including VSX* in future.
+* Once an instruction is allocated
   in an UnVectoriseable area it can never be Vectorised without providing
   an entirely new Encoding.