From: lkcl Date: Wed, 29 Mar 2023 20:21:52 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls012_v1~230 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=004f312dab1b11d79e5961e8db21fa0c5e6ec313;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index 791a78baf..d85e568cd 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -214,9 +214,16 @@ transformation"). Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops` (regardless of the prefix) - whereas when VL=1 and the SV prefix is all zeros, the operation simply - acts as if SV had not been applied at all to the instruction (an - "identity transformation"). +whereas when VL=1 and the SV prefix is all zeros, the operation simply +acts as if SV had not been applied at all to the instruction (an +"identity transformation"). + +The fact that is dynamic and can be set to any value at runtime based +on program conditions and behaviour means very specifically that +`scalar identity behaviour` is **not** a redundant encoding. If the +only means by which VL cold be set was by way of static-compiled +immediates then this assertion would be false. VL should not +be confused with MAXVL when understanding this key aspect of SimpleV. ## Register Naming and size @@ -252,58 +259,58 @@ Register). Further discussion is out of scope for this version of SVP64. \newpage{} -# Remapped Encoding (`RM[0:23]`) - -To allow relatively easy remapping of which portions of the Prefix Opcode -Map are used for SVP64 without needing to rewrite a large portion of the -SVP64 spec, a mapping is defined from the OpenPower v3.1 prefix bits to -a new 24-bit Remapped Encoding denoted `RM[0]` at the MSB to `RM[23]` -at the LSB. - -The mapping from the OpenPower v3.1 prefix bits to the Remapped Encoding -is defined in the Prefix Fields section. - -## Prefix Fields +# 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 EXT1xx. + +| 0-5 | 6 | 7 | 8-31 | 32| Description | +|-----|---|---|-------|---|------------------------------------| +| PO | 0 | x | xxxx | 0 | EXT200-232 or `RESERVED2` (56-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 | EXT300-363 or `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 RESERVED) it +is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,bits 8-31 +can be zero (termed `scalar identity behaviour`). SVP64Single shares its +Encoding space with Scalar Ext232-263 and Scalar EXT300-363. + +*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 or not be allocated at all. +This is required as an inviolate hard rule governing Primary Opcode 9* -TODO incorporate EXT09 - -To "activate" svp64 (in a way that does not conflict with v3.1B 64 -bit Prefix mode), fields within the v3.1B Prefix Opcode Map are set -(see Prefix Opcode Map, above), leaving 24 bits "free" for use by SV. -This is achieved by setting bits 7 and 9 to 1: - -| Name | Bits | Value | Description | -|------------|---------|-------|--------------------------------| -| EXT01 | `0:5` | `1` | Indicates Prefixed 64-bit | -| `RM[0]` | `6` | | Bit 0 of Remapped Encoding | -| SVP64_7 | `7` | `1` | Indicates this is SVP64 | -| `RM[1]` | `8` | | Bit 1 of Remapped Encoding | -| SVP64_9 | `9` | `1` | Indicates this is SVP64 | -| `RM[2:23]` | `10:31` | | Bits 2-23 of Remapped Encoding | - -Laid out bitwise, this is as follows, showing how the 32-bits of the prefix -are constructed: +# Remapped Encoding (`RM[0:23]`) -| 0:5 | 6 | 7 | 8 | 9 | 10:31 | -|--------|-------|---|-------|---|----------| -| EXT01 | RM | 1 | RM | 1 | RM | -| 000001 | RM[0] | 1 | RM[1] | 1 | RM[2: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 remainder of the +Defined Word. Note that the new EXT232-263 SVP64 area it is obviously mandatory +that bit 32 is required to be set. -Following the prefix will be the suffix: this is simply a 32-bit v3.0B -/ v3.1 instruction. That instruction becomes "prefixed" with the SVP -context: the Remapped Encoding field (RM). +| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-64 |Description | +|-----|---|---|----------|--------|----------|----------------------------------| +| PO | 0 | 1 | RM[0:23] | 1nnnnn | xxxxxxxx | SVP64:EXT232-263 | +| PO | 1 | 1 | RM[0:23] | nnnnnn | xxxxxxxx | SVP64:EXT000-063 | It is important to note that unlike v3.1 64-bit prefixed instructions there is insufficient space in `RM` to provide identification of any SVP64 Fields without first partially decoding the 32-bit suffix. Similar to the "Forms" (X-Form, D-Form) the `RM` format is individually associated -with every instruction. +with every instruction. However this still does not adversely affect Multi-Issue +Decoding because the identification of the 64-bit space has been kept brutally +simple. -Extreme caution and care must therefore be taken when extending SVP64 +Extreme caution and care must be taken when extending SVP64 in future, to not create unnecessary relationships between prefix and suffix that could complicate decoding, adding latency. -# Common RM fields +## Common RM fields The following fields are common to all Remapped Encodings: