(no commit message)

diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn
index 500ad33ab23653462049132970fec22abbaa8ce1..7d041298888fa7d3aa51da2a11a572e8941517ea 100644 (file)
--- a/openpower/sv/po9_encoding.mdwn
+++ b/openpower/sv/po9_encoding.mdwn
@@ -123,12 +123,14 @@ 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 a 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
   should not be permitted as long as it is clearly marked as UnVectoriseable.
@@ -140,7 +142,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.