From: lkcl Date: Sun, 23 Apr 2023 16:53:06 +0000 (+0100) Subject: (no commit message) X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f788b12ae5ec8b3b5c3c70e3daefa5e2c2bbc00f;p=libreriscv.git --- diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn index 500ad33ab..7d0412988 100644 --- 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.