(no commit message)
[libreriscv.git] / openpower / sv / po9_encoding.mdwn
index 500ad33ab23653462049132970fec22abbaa8ce1..7d041c06bacb4b86edb095bb64a2cd590325e4ed 100644 (file)
@@ -87,7 +87,8 @@ Key:
 * **x** - a `RESERVED` encoding. Illegal Instruction Trap must be raised
 * **n** - a specification-defined value
 * **!zero** - a non-zero specification-defined value
-* **DWd** - "Defined Word" as explained in Book I Section 1.6 (Public v3.1 p11)
+* **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,
@@ -123,14 +124,18 @@ Encoding spaces and their potential are illustrated:
 
 Notes:
 
-* PO9-PO1 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.
-* PO1-PO9 Prefixed-Prefixed (96-bit) instructions are also prohibited
+* 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 a 64-bit Encoding
+* 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)
@@ -140,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.