From: lkcl Date: Thu, 15 Sep 2022 14:10:49 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~425 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=bc1a5c1117fdabe6b0d8b8275b8b259920d9c143;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn index c2397d899..7c3ea253f 100644 --- a/openpower/sv/rfc/ls001.mdwn +++ b/openpower/sv/rfc/ls001.mdwn @@ -710,34 +710,59 @@ that is as follows: * EXT009, like EXT001 of Public v3.1, is **defined** as a 64-bit encoding -* bits 32-33 if 0b11 are indefinitely allocated to SVP64 Format +* 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 - - -There are unfortunately some inviolate requirements that directly place -pressure on the EXT000-EXT063 (32-bit) opcode space to such a degree that -it risks jeapordising the Power ISA. These requirements are: - -* all of the scalar operations must be Vectoriseable -* all of the scalar operations intended for Vectorisation - must be in a 32-bit encoding (not prefixed-prefixed to 96-bit) -* bringing Scalar Power ISA up-to-date from the past 12 years - needs 75% of two Major opcodes all on its own - -There exists a potential scheme which meets (exceeds) the above criteria, -providing plenty of room for both Scalar (and Vectorised) operations, -*and* provides SVP64-Single with room to grow. It -is based loosely around Public v3.1 EXT001 Encoding.[^ext001] - -| 0-5 | 6 | 7 | 8-31 | Description | -|-----|---|---|-------|---------------------------| -| PO | 0 | 0 | 0000 | new-suffix `RESERVED1` | -| PO | 0 | 0 | !zero | new-suffix, scalar (SVP64Single), or `RESERVED3` | -| PO | 1 | 0 | 0000 | new scalar-only word, or `RESERVED2` | -| PO | 1 | 0 | !zero | old-suffix, scalar (SVP64Single), or `RESERVED4` | -| PO | 0 | 1 | nnnn | new-suffix, vector (SVP64) | -| PO | 1 | 1 | nnnn | old-suffix, vector (SVP64) | + +| 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) # Example Legal Encodings and RESERVED spaces @@ -766,12 +791,13 @@ all cases. Anything other than this risks either damage (truncation of capabilities of Simple-V) or far greater complexity in the Decode Phase. -A *potential* compromise is to reserve certain EXT2nn POs right +This drives the compromise proposal (above) to reserve certain +EXT2nn POs right across the board (in the Scalar Suffix side, irrespective of Prefix), some allocated to Simple-V, some not. -example, legal (sort-of) (edit, typo corrected) +**example, legal (sort-of)* * 32bit fishmv EXT0nn 0x12345678 or 64bit scalar EXT2nn 0x240000000 0x12345678 @@ -779,7 +805,7 @@ example, legal (sort-of) (edit, typo corrected) this is sort-of-not-illegal because the space is automatically reserved for trap-and-emulate of Vector fishmv by Lower SV Compliancy Levels. -example ILLEGAL: (typo corrected) +**example ILLEGAL:** * 32bit fredmv EXT0nn 0x12345678 or 64bit scalar EXT2nn 0x240000000 0x12345678 @@ -787,7 +813,7 @@ example ILLEGAL: (typo corrected) the use of 0x12345678 for fredmv in scalar but fishmv in Vector is **not** okay. -another illegal example: (typo corrected) +**another illegal example:** * 32bit RESERVEDunallocated EXT0nn 0x12345678 or 64bit scalar EXT2nn 0x240000000 0x12345678