| PO | 1 | 0 | !zero | nn | SVP64Single:EXT000-063 or `RESERVED4` |
| PO | 1 | 1 | nnnn | nn | SVP64:EXT000-063 |
-and reserved areas are:
+and reserved areas, QTY 1of 30-bit and QTY 3of 55-bit, are:
| 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
|-----|---|---|-------|------|---------------------------|
| PO9?| 0 | x | xxxx | 0b10 | RESERVED (other) |
| PO9?| 0 | x | xxxx | 0b00 | RESERVED (other) |
-with additional potentially reserved areas (part of Scalar
-Unvectoriseable EXT200-247):
+with additional potentially QTY 3of 30-bit reserved areas
+(part of Scalar Unvectoriseable EXT200-247):
| 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
|-----|---|---|-------|------|---------------------------|
Where:
* SVP64Single (`RESERVED3/4`) is *planned* for a future RFC
+ (but needs reserving as part of this 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). However, it is important to note that in the
-EXT300-363 range, Simple-V will never under any circumstances be
-applicable to these opcodes.
-If EXT300-363 is ever considered at all by a future RFC,
-potential EXT348-363
-is strongly recommended to
-always be illegal instructions so as not to conflict with bits
-32-33 being 0b11 for Simple-V.
-
-Summary:
-
-* EXT3nn (if allocated) is restricted to range EXT300-347
-* EXT2nn is restricted to range EXT248-263
-* EXT0nn if Vectorised must maintain an equivalence map,
- only up to 16 Primary Opcodes
+* RESERVED2 is for "new" Scalar instructions (designated EXT248-263)
+ which **must** also simultaneously request the corresponding space
+ in SVP64, even if the instruction is non-Vectoriseable. Best
+ allocated to instructions that have the potential to be Simple-V-Vectorised
+* Anything Vectorised-EXT000-063 is **automatically** being
+ requested as 100% Reserved for every single "Defined Word"
+ (Public v3.1 1.6.3 definition).
+* Any **future** instruction
+ added to EXT000-063 likewise, is **automatically**
+ assigned corresponding reservations in the SVP64:EXT000-063
+ and SVP64Single:EXT000-063 area, regardless of whether the
+ instruction is Vectoriseable or not.
+
+Bit-allocation Summary:
+
+* EXT3nn and three other encodings provide space for non-Simple-V
+ operations to have QTY 4of EXTn00-EXTn47 Primary Opcode ranges
+* QTY 3of 55-bit spaces also exist for future use (longer by 3 bits
+ than opcodes allocated in EXT001)
+* Simple-V EXT2nn is restricted to range EXT248-263
+* non-Simple-V EXT2nn is restricted to range EXT200-247
+* Simple-V EXT0nn takes up 50% of PO9 for this and future Simple-V RFCs
+* The clear separation between Simple-V and non-Simple-V means there is
+ no possibility of future RFCs encroaching on the others' space.
\newpage{}
|--------|--------|
| PO | EXT000-063 Scalar (v3.0 or v3.1) operation |
-**RESERVED2 / EXT300-347** bit6=old bit7=scalar
+**SVP64Single:{EXT000-063}** bit6=old bit7=scalar
-This is entirely at the discretion of the ISA WG. Libre-SOC is *not*
-proposing the addition of EXT300-363: it is merely a possibility for
-future. The reason the space is not needed is because this is within
-the realm of Scalar-extended (SVP64Single), and with the 24-bit prefix
-area being all-zero (bits 8-31) this is defined as "having no augmentation"
-(in the Simple-V Specification it is termed `Scalar Identity Behaviour`).
-This in turn makes this prefix a *degenerate duplicate* so may be allocated
-for other purposes.
+This encoding, identical to SVP64Single:{EXT200-263},
+introduces SVP64Single Augmentation of v3.0 Scalar word instructions.
+All meanings must be identical to EXT000 to EXT063, and is is likewise
+prohibited to add an instruction in this area without also adding
+the exact same (non-Augmented) instruction in EXT000-063 with the
+exact same Scalar word.
+PO2 is in the range 0b00000 to 0b11111 to represent EXT000-063 respectively.
+Augmenting EXT001 is prohibited.
+
+| 0-5 | 6 | 7 | 8-31 | 32-63 |
+|--------|---|---|-------|---------|
+| PO (9)?| 1 | 0 | !zero | SVP64Single:{EXT000-063} |
+
+**SVP64:{EXT000-063}** bit6=old bit7=vector
+
+This encoding is identical to **SVP64:{EXT200-263}** except it
+is the Vectorisation of existing v3.0/3.1 Scalar-words, EXT000-063.
+All the same rules apply with the addition that
+Vectorisation of EXT001 is prohibited.
| 0-5 | 6 | 7 | 8-31 | 32-63 |
|--------|---|---|-------|---------|
-| PO (9)?| 1 | 0 | 0000 | EXT300-347 or `RESERVED1` |
-| PO (9)?| 1 | 0 | 0000 | EXT348-363 Illegal (always) |
+| PO (9)?| 1 | 1 | nnnn | SVP64:{EXT000-063} |
-**{EXT200-263}** bit6=new bit7=scalar
+**{EXT248-263}** bit6=new bit7=scalar
-This encoding represents the opportunity to introduce EXT200-263.
+This encoding represents the opportunity to introduce EXT248-263.
It is a Scalar-word encoding, and does not require implementing
-SVP64 or SVP64-Single.
-PO2 is in the range 0b00000 to 0b11111 to represent EXT200-263 respectively.
+SVP64 or SVP64-Single, but does require the Vector-space to be allocated.
+PO2 is in the range 0b11000 to 0b111111 to represent EXT248-263 respectively.
| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 0 | 0000 | 0b11 |PO2[2:5] | {EXT200-263} |
+| PO (9)?| 0 | 0 | 0000 | 0b11 |PO2[2:5] | {EXT248-263} |
-**SVP64Single:{EXT200-263}** bit6=new bit7=scalar
+**SVP64Single:{EXT248-263}** bit6=new bit7=scalar
This encoding, which is effectively "implicit VL=1"
and comprising (from bits 8-31)
*at least some* form of Augmentation, it represents the opportunity
-to Augment EXT200-263 with the SVP64Single capabilities.
-Instructions may not be placed in this category without also being
-implemented as pure Scalar.
+to Augment EXT248-263 with the SVP64Single capabilities.
+Must be allocated under Scalar *and* SVP64 simultaneously.
| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 0 | !zero | 0b11 |PO2[2:5] | SVP64Single:{EXT200-263} |
+| PO (9)?| 0 | 0 | !zero | 0b11 |PO2[2:5] | SVP64Single:{EXT248-263} |
-**SVP64Single:{EXT000-063}** bit6=old bit7=scalar
-
-This encoding, identical to SVP64Single:{EXT200-263},
-introduces SVP64Single Augmentation of v3.0 Scalar word instructions.
-All meanings must be identical to EXT000 to EXT063, and is is likewise
-prohibited to add an instruction in this area without also adding
-the exact same (non-Augmented) instruction in EXT000-063 with the
-exact same Scalar word.
-PO2 is in the range 0b00000 to 0b11111 to represent EXT000-063 respectively.
-Augmenting EXT001 is prohibited.
-
-| 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
+**SVP64:{EXT248-263}** bit6=new bit7=vector
This encoding, which permits VL to be dynamic (settable from GPR or CTR)
-is the Vectorisation of EXT200-263.
+is the Vectorisation of EXT248-263.
Instructions may not be placed in this category without also being
implemented as pure Scalar *and* SVP64Single. Unlike SVP64Single
however, there is **no reserved encoding** (bits 8-24 zero).
| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 1 | nnnn | 0b11 |PO2[2:5] | SVP64:{EXT200-263} |
+| PO (9)?| 0 | 1 | nnnn | 0b11 |PO2[2:5] | SVP64:{EXT248-263} |
-**SVP64:{EXT000-063}** bit6=old bit7=vector
+**RESERVED2 / EXT300-363** bit6=old bit7=scalar
-This encoding is identical to **SVP64:{EXT200-263}** except it
-is the Vectorisation of existing v3.0/3.1 Scalar-words, EXT000-063.
-All the same rules apply with the addition that
-Vectorisation of EXT001 is prohibited.
+This is entirely at the discretion of the ISA WG. Libre-SOC is *not*
+proposing the addition of EXT300-363: it is merely a possibility for
+future. The reason the space is not needed is because this is within
+the realm of Scalar-extended (SVP64Single), and with the 24-bit prefix
+area being all-zero (bits 8-31) this is defined as "having no augmentation"
+(in the Simple-V Specification it is termed `Scalar Identity Behaviour`).
+This in turn makes this prefix a *degenerate duplicate* so may be allocated
+for other purposes.
-| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
-|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 1 | 1 | nnnn |0b11 |PO2[2:5] | SVP64:{EXT000-063} |
+| 0-5 | 6 | 7 | 8-31 | 32-63 |
+|--------|---|---|-------|---------|
+| PO (9)?| 1 | 0 | 0000 | EXT300-363 or `RESERVED1` |
\newpage{}
# Example Legal Encodings and RESERVED spaces
projects / libreriscv.git / commitdiff