From fdbd9aa4bce6ed45e2855eaaf0db125da8d89d1e Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Mon, 3 Apr 2023 11:44:48 +0100 Subject: [PATCH] move PO9 definition --- openpower/sv/svp64.mdwn | 136 +++++++++++++++++++++------------------- 1 file changed, 70 insertions(+), 66 deletions(-) diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 99eb7a289..3e7d94833 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -443,72 +443,7 @@ of scope for this version of SVP64. \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. - -# Remapped Encoding (`RM[0:23]`) +## SVP64 Remapped Encoding (`RM[0:23]`) In the SVP64 Vector Prefix spaces, the 24 bits 8-31 are termed `RM`. Bits 32-37 are the Primary Opcode of the Suffix "Defined Word". 38-63 are the @@ -1068,3 +1003,72 @@ Now at its own page: [[svp64/appendix]] \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