From: Luke Kenneth Casson Leighton Date: Fri, 9 Sep 2022 19:51:31 +0000 (+0100) Subject: add potential opcode solution to rfc ls001 X-Git-Tag: opf_rfc_ls005_v1~547 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=d0d4ce8a0c81de1ef5718879ec49e14bf8af9225;p=libreriscv.git add potential opcode solution to rfc ls001 --- diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn index 236494cc4..c0240d57c 100644 --- a/openpower/sv/rfc/ls001.mdwn +++ b/openpower/sv/rfc/ls001.mdwn @@ -274,6 +274,72 @@ For each of EXT059 and EXT063: [under evaluation](https://bugs.libre-soc.org/show_bug.cgi?id=923) as of 08Sep2022 +\newpage{} +# Potential Opcode allocation + +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 the same amount of room to grow. It +is based loosely around the existing Public v3.1 EXT001 Encoding +Scheme. + +| 0-5 | 6 | 7 | 8-31 | Description | +|-----|---|---|-------|---------------------------| +| PO | 0 | 0 | 0000 | `RESERVED1` | +| PO | 0 | 0 | !zero | new-suffix, scalar (SVP64Single) | +| PO | 1 | 0 | 0000 | `RESERVED2` | +| PO | 1 | 0 | !zero | old-suffix, scalar (SVP64Single) | +| PO | 0 | 1 | nnnn | new-suffix, vector (SVP64) | +| PO | 1 | 1 | nnnn | old-suffix, vector (SVP64) | + +The above table requires some explanation, with some definitions. + +* **PO** - Primary Opcode. Likely candidates: EXT022, EXT005, EXT009 +* **bit 6** - specifies whether the suffix is old (EXT000-EXT063) + or new (EXTn00-EXTn63, n greater than 1) +* **bit 7** - defines whether the Suffix is Scalar-Prefixed or Vector-Prefixed + (caveat: see bits 8-31) +* **old-suffix** - the EXT000 to EXT063 32-bit Major opcodes of Power ISA 3.0 +* **new-suffix** - two **new** Major Opcode areas **exclusively** + for Scalar-only instructions that shall **never** be Prefixed by SVP64: + RESERVED1 EXT200-EXT263 and + RESERVED2 EXT300-EXT363 +* **0000** - all 24 bits bits 8-31 are zero (0x000000) +* **!zero** - bits 8-31 may be any value *other* than zero +* **nnnn** - bits 8-31 may be any value in the range 0x000000 to 0xffffff +* **SVP64Single** - a (TBD) Encoding that is near-identical to SVP64 + except that it is not a Vector Operation (equivalent to hard-coded VL=1 + at all times). Predication is permitted, Element-width-overrides is + permitted, Saturation is permitted. SVP64Single is a **scalar** augmentation + of its suffix. +* **SVP64** - a (well-defined, 2 years) DRAFT Proposal for a Vectorisation + Augmentation of suffixes. + +(*For completeness, we recall that EXT100 to EXT163 is the numbering for +Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which, +in Section 1.6.3, we note that bit 6 is set to 1. This concept is where +the above scheme originated. Section 1.6.3 uses the term "defined word" +to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed +to create the new numbering EXT100-EXT163, respectively*) + +The opportunity to create two new 32-bit encoding spaces each with +64 Major opcodes each is best made with another table: + +| | Scalar (bit7=0,8-31=0000) | Scalar (bit7=0,8-31=!zero)| Vector (bit7=1) | +|----------|---------------------------|---------------------------|------------------| +|new bit6=0| `RESERVED1`:{EXT200-063} | SVP64-Single:{EXT200-263} | SVP64:{EXT200-263} | +|old bit6=1| `RESERVED2`:{EXT300-363} | SVP64-Single:{EXT000-063} | SVP64:{EXT000-063} | + \newpage{} # Use cases