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
\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:
projects / libreriscv.git / commitdiff