some of which are common to all Suffixes, and some Mode bits are specific
to the Defined Word class: Load/Store-Immediate, Load/Store-Indexed,
Arithmetic/Logical, Condition Register operations, and Branch-Conditional.
-Anything not falling into those five categories is termed "UnVectoriseable".
+Anything not falling into those five categories is termed "Unvectorizable".
**Definition of Horizontal-First:**
instructions that normally would not have it. *SVP64Single is in Draft only*
and is yet to be defined.
-**Definition of "UnVectoriseable":**
+**Definition of "Unvectorizable":**
Any operation that inherently makes no sense if repeated (through SVP64
-Prefixing) is termed "UnVectoriseable" or "UnVectorised". Examples
+Prefixing) is termed "Unvectorizable". Examples
include `sc` or `sync` which have no registers. `mtmsr` is also classed
-as UnVectoriseable because there is only one `MSR`.
+as Unvectorizable because there is only one `MSR`.
-UnVectorised instructions are required to be detected as such if Prefixed
+Unvectorizable instructions are required to be detected as such if Prefixed
(either SVP64 or SVP64Single) and an Illegal Instruction Trap raised.
*Hardware Architectural Note: Given that a "pre-classification" Decode Phase
is required (identifying whether the Suffix - Defined Word - is
Arithmetic/Logical, CR-op, Load/Store or Branch-Conditional), adding
-"UnVectorised" to this phase is not unreasonable.*
+"Unvectorizable" to this phase is not unreasonable.*
# New 64-bit Instruction Encoding spaces
**under no circumstances** must different Defined Words (different from
the same **Un-Prefixed** Defined Word) be allocated within any `EXT{z}`
prefixed or unprefixed space for a given value of `z` of 0, 2 or 3: the
-results would be catastrophic. Even if UnVectoriseable an instruction
+results would be catastrophic. Even if Unvectorizable 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
+Trap if Unvectorizable) 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
Notes:
* **PO9**-PO1 Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
- thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
+ thus inherently Unvectorizable 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.
* There is however no reason why PO9-PO1 (EXT901?) as an entirely new RESERVED
64-bit Encoding
- should not be permitted as long as it is clearly marked as UnVectoriseable.
+ should not be permitted as long as it is clearly marked as Unvectorizable.
* PO1-**PO9** Prefixed-Prefixed (96-bit) instructions are also prohibited
for the same reason: Multi-Issue Decode complexity is too great.
* There is however no reason why PO1-PO9 (EXT109) as an entirely new RESERVED
64-bit Encoding
- should not be permitted as long as it is clearly marked as UnVectoriseable.
+ should not be permitted as long as it is clearly marked as Unvectorizable.
* EXT100-163 instructions (PO1-Prefixed) are also prohibited from being
double-PO1-prefixed (not twice prefixed)
* 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
+ that the area is Unvectorizable and also cannot be Prefixed with
SVP64Single.
* Considerable care is needed both on Architectural Resource Allocation
as well as instruction design itself. All new Scalar instructions automatically
and inherently must be designed taking their Vectoriseable potential into
consideration *including VSX* in future.
* Once an instruction is allocated
- in an UnVectoriseable area it can never be Vectorised without providing
+ in an Unvectorizable area it can never be Vectorised without providing
an entirely new Encoding.
[[!tag standards]]
which is a different convention from that used elsewhere in the Power ISA.
The SVP64 prefix always comes before the suffix in PC order and must be
-considered an independent "Defined word" that augments the behaviour of
-the following instruction, but does **not** change the actual Decoding
-of that following instruction. **All SVP64-prefixed 32-bit instructions
-(Defined Words) retain their non-prefixed encoding and definition**.
+considered an independent "Defined word-instruction"[^dwi] that augments the behaviour of
+the following instruction (also a Defined word-instruction), but does **not** change the actual Decoding
+of that following instruction just because it is Prefixed. Unlike EXT100-163,
+where the Suffix is considered an entirely new Opcode Space,
+SVP64-Prefixed instructions **MUST NEVER** be treated or regarded
+as a different Opcode Space.
+
+[^dwi]: Defined Word-instruction: Power ISA v3.1 Section 1.6
+
+*Architectural note: Treating the SVP64 Prefix as an "Independent" 64-bit Encoding Space and attempting
+to allocate non-Orthogonal Opcodes within it will result
+in catastrophic unviability of Simple-V. The Orthogonality of the Scalar vs Prefixed-Scalar
+spaces has to be considered inviolate, to the extent that even RESERVED spaces must be
+kept identical. The complexity at the Decode Phase by violating the RISC paradigm inherent
+in Simple-V will be unimplementable*
Two apparent exceptions to the above hard rule exist: SV
Branch-Conditional operations and LD/ST-update "Post-Increment"
projects / libreriscv.git / commitdiff