replace occurrences of UnVectoriseable with Unvectorizable
[libreriscv.git] / openpower / sv / po9_encoding.mdwn
index 8ceeadde32ed478b96c7befb9c84f54f745771cd..3ad335b9366b9a0ee15e13c930eaf2c17a397e25 100644 (file)
@@ -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]]