From: Luke Kenneth Casson Leighton Date: Mon, 29 May 2023 12:22:00 +0000 (+0100) Subject: replace occurrences of UnVectoriseable with Unvectorizable X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f560e31ee704fe4775e43849c779b800ee4b32cc;p=libreriscv.git replace occurrences of UnVectoriseable with Unvectorizable --- diff --git a/openpower/sv/po9_encoding.mdwn b/openpower/sv/po9_encoding.mdwn index 8ceeadde3..3ad335b93 100644 --- a/openpower/sv/po9_encoding.mdwn +++ b/openpower/sv/po9_encoding.mdwn @@ -21,7 +21,7 @@ in a 32-bit Prefix format, that exploits the following instruction 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:** @@ -51,20 +51,20 @@ element-width overrides, and optionally adds Saturation to Arithmetic 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 @@ -108,10 +108,10 @@ the Suffix, the Suffix is entirely independent of the Prefix. Therefore **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 @@ -143,31 +143,31 @@ Encoding spaces and their potential are illustrated: 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]] diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 762d6877d..d97b24f2f 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -66,10 +66,21 @@ ranges are inclusive (so `4:6` means bits 4, 5, and 6, in MSB0 order). 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"