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