From: lkcl Date: Sun, 23 Apr 2023 17:28:51 +0000 (+0100) Subject: (no commit message) X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=fb286493c46a1de7c35965428b32f671a1c3b3bc;p=libreriscv.git --- diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn index 7d0412988..7d041c06b 100644 --- a/openpower/sv/po9_encoding.mdwn +++ b/openpower/sv/po9_encoding.mdwn @@ -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, @@ -128,11 +129,13 @@ Notes: 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 a 64-bit Encoding +* 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)