From 890b1d4541cd70899dc1ec5b0f9550563292448b Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Mon, 3 Apr 2023 11:48:00 +0100 Subject: [PATCH] move po9 encoding to its own separate page --- openpower/sv/po9_encoding.mdwn | 71 ++++++++++++++++++++++++++++++++++ openpower/sv/rfc/Makefile | 2 + openpower/sv/svp64.mdwn | 71 ---------------------------------- 3 files changed, 73 insertions(+), 71 deletions(-) create mode 100644 openpower/sv/po9_encoding.mdwn diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn new file mode 100644 index 000000000..9714d695c --- /dev/null +++ b/openpower/sv/po9_encoding.mdwn @@ -0,0 +1,71 @@ +# New 64-bit Instruction Encoding spaces + +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 | + +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. + +Also that RESERVED1 and 2 are candidates for future Major opcode +areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas +they may equally be allocated entirely differently. + +*Architectural Resource Allocation Note: **under no circumstances** must +different Defined Words be allocated within any `EXT{z}` prefixed +or unprefixed space for a given value of `z`. Even if UnVectoriseable +an instruction Defined Word space must have the exact same Instruction +and exact same Instruction Encoding in all spaces being RESERVED - Illegal +Instruction Trap - if UnVectoriseable) or not be allocated at all. +This is required as an inviolate hard rule governing Primary Opcode 9 +that may not be revoked under any circumstances. A useful way to think +of this is that the Prefix Encoding is, like the 8086 REP instruction, +an independent 32-bit Defined Word. The only semi-exceptions are +the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.* + +Encoding spaces and their potential are illustrated: + +| Encoding | Available bits | Scalar | Vectoriseable | SVP64Single | +|----------|----------------|--------|---------------|--------------| +|EXT000-063| 32 | yes | yes |yes | +|EXT100-163| 64 | yes | no |no | +|RESERVED2 | 57 | N/A |not applicable |not applicable| +|EXT232-263| 32 | yes | yes |yes | +|RESERVED1 | 32 | N/A | no |no | + +Notes: + +* 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. +* RESERVED2 presently remains unallocated as of yet and therefore its + potential is not yet defined (Not Applicable). +* RESERVED1 is also unallocated at present, but it is known in advance + 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 + in an UnVectoriseable area it can never be Vectorised without providing + an entirely new Encoding. + +[[!tag standards]] + +-------- + +\newpage{} + diff --git a/openpower/sv/rfc/Makefile b/openpower/sv/rfc/Makefile index c72544607..a06826d42 100644 --- a/openpower/sv/rfc/Makefile +++ b/openpower/sv/rfc/Makefile @@ -4,6 +4,7 @@ LSO10_FILES = ls010.mdwn ../svp64.mdwn \ ../normal.mdwn \ ../ldst.mdwn \ ../branches.mdwn \ + ../po9_encoding.mdwn \ ../cr_ops.mdwn ls010.pdf: $(LS010_FILES) @@ -18,6 +19,7 @@ ls010.pdf: $(LS010_FILES) -V linkcolor=blue \ -f markdown \ sv/rfc/ls010.mdwn \ + sv/po9_encoding.mdwn \ sv/svp64.mdwn \ sv/normal.mdwn \ sv/ldst.mdwn \ diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 3e7d94833..6486b075d 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -1001,74 +1001,3 @@ Now at its own page: [[svp64/appendix]] [[!tag standards]] \newpage{} - - -# New 64-bit Instruction Encoding spaces - -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 | - -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. - -Also that RESERVED1 and 2 are candidates for future Major opcode -areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas -they may equally be allocated entirely differently. - -*Architectural Resource Allocation Note: **under no circumstances** must -different Defined Words be allocated within any `EXT{z}` prefixed -or unprefixed space for a given value of `z`. Even if UnVectoriseable -an instruction Defined Word space must have the exact same Instruction -and exact same Instruction Encoding in all spaces being RESERVED - Illegal -Instruction Trap - if UnVectoriseable) or not be allocated at all. -This is required as an inviolate hard rule governing Primary Opcode 9 -that may not be revoked under any circumstances. A useful way to think -of this is that the Prefix Encoding is, like the 8086 REP instruction, -an independent 32-bit Defined Word. The only semi-exceptions are -the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.* - -Encoding spaces and their potential are illustrated: - -| Encoding | Available bits | Scalar | Vectoriseable | SVP64Single | -|----------|----------------|--------|---------------|--------------| -|EXT000-063| 32 | yes | yes |yes | -|EXT100-163| 64 | yes | no |no | -|RESERVED2 | 57 | N/A |not applicable |not applicable| -|EXT232-263| 32 | yes | yes |yes | -|RESERVED1 | 32 | N/A | no |no | - -Notes: - -* 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. -* RESERVED2 presently remains unallocated as of yet and therefore its - potential is not yet defined (Not Applicable). -* RESERVED1 is also unallocated at present, but it is known in advance - 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 - in an UnVectoriseable area it can never be Vectorised without providing - an entirely new Encoding. - --------- - -\newpage{} - -- 2.30.2