\newpage{}
-# 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 Primary Opcode 1
-(EXT1xx).
-
-| 0-5 | 6 | 7 | 8-31 | 32| Description |
-|-----|---|---|-------|---|------------------------------------|
-| PO | 0 | x | xxxx | 0 | `RESERVED2` (57-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 | `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 RESERVED3 and 4)
-it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
-for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
-prohibition allows SVP64Single to share its Encoding space with Scalar
-Ext232-263 and Scalar EXT300-363.
-
-Also that RESERVED1 and 2 are candidates for future Major opcode
-areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
-they may equally be allocated entirely differently.
-
-*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 being RESERVED - Illegal
-Instruction Trap - if UnVectoriseable) or not be allocated at all.
-This is required as an inviolate hard rule governing Primary Opcode 9
-that may not be revoked under any circumstances. A useful way to think
-of this is that the Prefix Encoding is, like the 8086 REP instruction,
-an independent 32-bit Defined Word. The only semi-exceptions are
-the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.*
-
-Encoding spaces and their potential are illustrated:
-
-| Encoding | Available bits | Scalar | Vectoriseable | SVP64Single |
-|----------|----------------|--------|---------------|--------------|
-|EXT000-063| 32 | yes | yes |yes |
-|EXT100-163| 64 | yes | no |no |
-|RESERVED2 | 57 | N/A |not applicable |not applicable|
-|EXT232-263| 32 | yes | yes |yes |
-|RESERVED1 | 32 | N/A | no |no |
-
-Notes:
-
-* Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
- thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
- on top of an SVP64 prefix which is 32-bit on top of a Defined Word
- and the complexity at the Decoder becomes too great for High
- Performance Multi-Issue systems.
-* RESERVED2 presently remains unallocated as of yet and therefore its
- potential is not yet defined (Not Applicable).
-* RESERVED1 is also unallocated at present, but it is known in advance
- that the area is UnVectoriseable and also cannot be Prefixed with
- SVP64Single.
-* Considerable care is needed both on Architectural Resource Allocation
- as well as instruction design itself. Once an instruction is allocated
- in an UnVectoriseable area it can never be Vectorised without providing
- an entirely new Encoding.
-
-# Remapped Encoding (`RM[0:23]`)
+## SVP64 Remapped Encoding (`RM[0: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
\newpage{}
+# 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 Primary Opcode 1
+(EXT1xx).
+
+| 0-5 | 6 | 7 | 8-31 | 32| Description |
+|-----|---|---|-------|---|------------------------------------|
+| PO | 0 | x | xxxx | 0 | `RESERVED2` (57-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 | `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 RESERVED3 and 4)
+it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
+for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
+prohibition allows SVP64Single to share its Encoding space with Scalar
+Ext232-263 and Scalar EXT300-363.
+
+Also that RESERVED1 and 2 are candidates for future Major opcode
+areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
+they may equally be allocated entirely differently.
+
+*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 being RESERVED - Illegal
+Instruction Trap - if UnVectoriseable) or not be allocated at all.
+This is required as an inviolate hard rule governing Primary Opcode 9
+that may not be revoked under any circumstances. A useful way to think
+of this is that the Prefix Encoding is, like the 8086 REP instruction,
+an independent 32-bit Defined Word. The only semi-exceptions are
+the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.*
+
+Encoding spaces and their potential are illustrated:
+
+| Encoding | Available bits | Scalar | Vectoriseable | SVP64Single |
+|----------|----------------|--------|---------------|--------------|
+|EXT000-063| 32 | yes | yes |yes |
+|EXT100-163| 64 | yes | no |no |
+|RESERVED2 | 57 | N/A |not applicable |not applicable|
+|EXT232-263| 32 | yes | yes |yes |
+|RESERVED1 | 32 | N/A | no |no |
+
+Notes:
+
+* Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
+ thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
+ on top of an SVP64 prefix which is 32-bit on top of a Defined Word
+ and the complexity at the Decoder becomes too great for High
+ Performance Multi-Issue systems.
+* RESERVED2 presently remains unallocated as of yet and therefore its
+ potential is not yet defined (Not Applicable).
+* RESERVED1 is also unallocated at present, but it is known in advance
+ that the area is UnVectoriseable and also cannot be Prefixed with
+ SVP64Single.
+* Considerable care is needed both on Architectural Resource Allocation
+ as well as instruction design itself. Once an instruction is allocated
+ in an UnVectoriseable area it can never be Vectorised without providing
+ an entirely new Encoding.
+
+--------
+
+\newpage{}
+
projects / libreriscv.git / commitdiff