From 0cb647c4068ab25a861829a5f7ce2a39f556160b Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 15 Sep 2022 15:54:51 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls001.mdwn | 160 +++++++++++++++++++----------------- 1 file changed, 83 insertions(+), 77 deletions(-) diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn index 7c3ea253f..ab5b8cb79 100644 --- a/openpower/sv/rfc/ls001.mdwn +++ b/openpower/sv/rfc/ls001.mdwn @@ -613,6 +613,73 @@ The issues of allocation for bitmanip etc. from Libre-SOC is therefore overwhelmingly made moot. The only downside is that there is no `SVP64-Reserved` which will have to be achieved with SPRs (PCR or MSR). +# Potential Opcode allocation solution (2) + +One of the risks of the bit 6/7 scheme above is that there is no +room to share PO9 (EXT009) with other potential uses. A workaround for +that is as follows: + +* EXT009, like EXT001 of Public v3.1, is **defined** as a 64-bit + encoding +* bits 32-33 if 0b11 are **defined** as allocated to SVP64 Format + *regardless of what that is* +* other combinations of bits 32-33 are `RESERVED` for other purposes + +| 0-5 | 6 | 7 | 8-31 | 32:33 | Description | +|-----|---|---|-------|-------|---------------------------| +| PO9?| / | / | //// | 11 | SVP64 (current and future) | +| PO9?| / | / | //// | 01 | RESERVED (other) | +| PO9?| / | / | //// | 10 | RESERVED (other) | +| PO9?| / | / | //// | 00 | RESERVED (other) | + +This ensures that any potential for future conflict over uses of the +EXT009 space, jeapordising Simple-V in the process, are avoided. + +SVP64 then becomes: + +| 0-5 | 6 | 7 | 8-31 | 32-3 | Description | +|-----|---|---|-------|------|---------------------------| +| PO | 0 | 0 | 0000 | 0b11 | `RESERVED1` or EXT300-363 | +| PO | 0 | 0 | !zero | 0b11 | SVP64Single:EXT200-263, or `RESERVED3` | +| PO | 1 | 0 | 0000 | 0b11 | EXT200-264 or `RESERVED2` | +| PO | 1 | 0 | !zero | 0b11 | SVP64Single:EXT000-063 or `RESERVED4` | +| PO | 0 | 1 | nnnn | 0b11 | SVP64:EXT200-263 | +| PO | 1 | 1 | nnnn | 0b11 | SVP64:EXT000-063 | + +Where: + +* SVP64Single (`RESERVED3/4`) is *planned* for a future RFC +* `RESERVED1` is available for general-purpose **never**-Simple-V + 32-bit encodings + +The only potential difficulty (solvable with a mapping table) +is in fulfilling the "uniform suffix" requirement for `SVP64:EXT000-063` +(and SVP64Single in future). Example: + +| width | assembler | prefix? | 32-3 | suffix | description | +|-------|-----------|--------------|------|-----------|---------------| +| 32bit | fishmv | none | n/a | 345678| scalar EXT0nn | +| 64bit | ss.fishmv | 0x26!zero | 0b11 | 345678| scalar SVP64Single:EXT0nn | +| 64bit | sv.fishmv | 0x27nnnnnn | 0b11 | 345678| vector SVP64:EXT0nn | + +Note that the suffix would be bits 0-31 for 32-bit, and 34-63 in 64-bit, +where bits 2-31 of 32-bit Scalar are **required** to be the same as 34-63 +in 64-bit, which hints at a potential problem. + +In a 32-bit-only Encoding, EXT000-063 the requirement of the top two bits +being 0b11 effectively **requires** 32-bit-only instructions to be in the +numbering range 48-63. For `EXT248-263` this is clearly not a problem +but to restrict Vectorisation to only `EXT048-063` just as clearly is. + +A solution therefore is to maintain a "mapping table" between PO in +the range `EXT000-EXT047` to fit into the remaining 4 bits of PO2, where +the pattern chosen should minimise the number of gates to the bare +minimum. + +Note that this has no effect on or relation to other `RESERVED` +uses of bits 32-3 +(0b00/0b01/0b10) + \newpage{} **EXT000-EXT063** @@ -645,9 +712,9 @@ It is a Scalar-word encoding, and does not require implementing SVP64 or SVP64-Single. PO2 is in the range 0b00000 to 0b11111 to represent EXT200-263 respectively. -| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | -|--------|---|---|-------|--------|---------| -| PO (9)?| 0 | 0 | 0000 | PO2 | {EXT200-263} | +| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 | +|--------|---|---|-------|------|---------|---------| +| PO (9)?| 0 | 0 | 0000 | 0b11 |PO2[2:5] | {EXT200-263} | **SVP64Single:{EXT200-263}** bit6=new bit7=scalar @@ -658,9 +725,9 @@ to Augment EXT200-263 with the SVP64Single capabilities. Instructions may not be placed in this category without also being implemented as pure Scalar. -| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | -|--------|---|---|-------|--------|---------| -| PO (9)?| 0 | 0 | !zero | PO2 | SVP64Single:{EXT200-263} | +| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 | +|--------|---|---|-------|------|---------|---------| +| PO (9)?| 0 | 0 | !zero | 0b11 |PO2[2:5] | SVP64Single:{EXT200-263} | **SVP64Single:{EXT000-063}** bit6=old bit7=scalar @@ -673,9 +740,9 @@ exact same Scalar word. PO2 is in the range 0b00000 to 0b11111 to represent EXT000-063 respectively. Augmenting EXT001 is prohibited. -| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | -|--------|---|---|-------|--------|---------| -| PO (9)?| 1 | 0 | !zero | PO2 | SVP64Single:{EXT000-063} | +| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 | +|--------|---|---|-------|------|---------|---------| +| PO (9)?| 1 | 0 | !zero | 0b11 |PO2[2:5] | SVP64Single:{EXT000-063} | **SVP64:{EXT200-263}** bit6=new bit7=vector @@ -687,9 +754,9 @@ however, there is **no reserved encoding** (bits 8-24 zero). VL=1 may occur dynamically at runtime, even when bits 8-31 are zero. -| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | -|--------|---|---|-------|--------|---------| -| PO (9)?| 0 | 1 | nnnn | PO2 | SVP64:{EXT200-263} | +| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 | +|--------|---|---|-------|------|---------|---------| +| PO (9)?| 0 | 1 | nnnn | 0b11 |PO2[2:5] | SVP64:{EXT200-263} | **SVP64:{EXT000-063}** bit6=old bit7=vector @@ -698,72 +765,11 @@ is the Vectorisation of existing v3.0/3.1 Scalar-words, EXT000-063. All the same rules apply with the addition that Vectorisation of EXT001 is prohibited. -| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | -|--------|---|---|-------|--------|---------| -| PO (9)?| 1 | 1 | nnnn | PO2 | SVP64:{EXT000-063} | - -# Potential Opcode allocation solution (2) - -One of the risks of the bit 6/7 scheme above is that there is no -room to share PO9 (EXT009) with other potential uses. A workaround for -that is as follows: - -* EXT009, like EXT001 of Public v3.1, is **defined** as a 64-bit - encoding -* bits 32-33 if 0b11 are **defined** as allocated to SVP64 Format - *regardless of what that is* -* other combinations of bits 32-33 are `RESERVED` for other purposes - -| 0-5 | 6 | 7 | 8-31 | 32:33 | Description | -|-----|---|---|-------|-------|---------------------------| -| PO9?| / | / | //// | 11 | SVP64 (current and future) | -| PO9?| / | / | //// | 01 | RESERVED (other) | -| PO9?| / | / | //// | 10 | RESERVED (other) | -| PO9?| / | / | //// | 00 | RESERVED (other) | - -This ensures that any potential for future conflict over uses of the -EXT009 space, jeapordising Simple-V in the process, are avoided. - -SVP64 then becomes: - -| 0-5 | 6 | 7 | 8-31 | 32-3 | Description | -|-----|---|---|-------|------|---------------------------| -| PO | 0 | 0 | 0000 | 0b11 | `RESERVED1` or EXT300-363 | -| PO | 0 | 0 | !zero | 0b11 | SVP64Single:EXT200-263, or `RESERVED3` | -| PO | 1 | 0 | 0000 | 0b11 | EXT200-264 or `RESERVED2` | -| PO | 1 | 0 | !zero | 0b11 | SVP64Single:EXT000-063 or `RESERVED4` | -| PO | 0 | 1 | nnnn | 0b11 | SVP64:EXT200-263 | -| PO | 1 | 1 | nnnn | 0b11 | SVP64:EXT000-063 | - -Where: - -* SVP64Single (`RESERVED3/4`) is *planned* for a future RFC -* `RESERVED1` is available for general-purpose **never**-Simple-V - 32-bit encodings - -The only potential difficulty (solvable with a mapping table) -is in fulfilling the "uniform suffix" requirement for `SVP64:EXT000-063` -(and SVP64Single in future). Example: - -| width | assembler | prefix? | 32-3 | 34-63 | description | -|-------|-----------|--------------|------|-----------|---------------| -| 32bit | fishmv | none | n/a | 345678| scalar EXT0nn | -| 64bit | ss.fishmv | 0x26!zero | 0b11 | 345678| scalar SVP64Single:EXT0nn | -| 64bit | sv.fishmv | 0x27nnnnnn | 0b11 | 345678| vector SVP64:EXT0nn | - -In a 32-bit-only Encoding, EXT000-063 the requirement of the top two bits -being 0b11 effectively **requires** 32-bit-only instructions to be in the -numbering range 48-63. For `EXT248-263` this is clearly not a problem -but to restrict Vectorisation to only `EXT048-063` just as clearly is. - -A solution therefore is to maintain a "mapping table" between PO in -the range `EXT000-EXT047` to fit into the remaining 4 bits of PO2, where -the pattern chosen should minimise the number of gates to the bare -minimum. - -Note that this has no effect on or relation to other uses of bits 32-3 -(0b00/0b01/0b10) +| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 | +|--------|---|---|-------|------|---------|---------| +| PO (9)?| 1 | 1 | nnnn |0b11 |PO2[2:5] | SVP64:{EXT000-063} | +\newpage{} # Example Legal Encodings and RESERVED spaces This section illustrates what is legal encoding, what is not, and -- 2.30.2