openpower/sv/po9_encoding.mdwn

   1 # Definitions
   2
   3 **Add the following Definitions to Section 1.3.1 of Book I**
   4
   5 **Definition of Simple-V:**
   6
   7 In its simplest form, the Simple-V Loop/Vector concept is a Prefixing
   8 system (similar to the 8086 `REP` instruction and the Z80 `LDIR`)
   9 that both augments its
  10 following Defined Word Suffix, and also may repeat that instruction
  11 with optional sequential register offsets from those given in the
  12 Suffix. Register numbers may also be extended (larger register files).
  13 More advanced features add predication, element-width overrides, and
  14 Vertical-First Mode.
  15
  16 **Definition of SVP64 Prefixing:**
  17
  18 SVP64 is a well-defined implementation of the Simple-V Loop/Vector concept,
  19 in a 32-bit Prefix format, that exploits the following instruction
  20 (the Defined Word) using it as a "template".  It requires 24 bits,
  21 some of which are common to all Suffixes, and some Mode bits are specific
  22 to the Defined Word class: Load/Store-Immediate, Load/Store-Indexed,
  23 Arithmetic/Logical, Condition Register operations, and Branch-Conditional.
  24 Anything not falling into those five categories is termed "UnVectoriseable".
  25
  26 **Definition of Horizontal-First:**
  27
  28 Normal Cray-style Vectorisation, designated Horizontal-First, performs
  29 element-level operations (often in parallel) before moving in the usual
  30 fashion to the next instruction. The term "Horizontal-First"
  31 stems from naturally visually listing program instructions vertically,
  32 and register file contents horizontally, whereupon it is clear that
  33 register-elements are prioritised.
  34
  35 **Definition of Vertical-First:**
  36
  37 Vertical-First executes
  38 *one element operation only* then moves on to the next instruction,
  39 whereupon if that is also an SVP64-Prefixed instruction the exact same
  40 element offset is used.  Element offsets are then explicitly advanced
  41 by calling a special instruction, `svstep`. The term "Vertical-First"
  42 stems from naturally visually listing program instructions vertically
  43 and register file contents horizontally, where moving to the next
  44 instruction is a clear priority.
  45
  46 **Definition of SVP64Single Prefixing:**
  47
  48 A 32-bit Prefix in front of a Defined Word that extends register
  49 numbers (allows larger register files), adds single-bit predication,
  50 element-width overrides, and optionally adds Saturation to Arithmetic
  51 instructions that normally would not have it.  *SVP64Single is in Draft only*
  52 and is yet to be defined.
  53
  54 **Definition of "UnVectoriseable":**
  55
  56 Any operation that inherently makes no sense if repeated (through SVP64
  57 Prefixing) is termed "UnVectoriseable" or "UnVectorised".  Examples
  58 include `sc` or `sync` which have no registers. `mtmsr` is also classed
  59 as UnVectoriseable because there is only one `MSR`.
  60
  61 UnVectorised instructions are required to be detected as such if Prefixed
  62 (either SVP64 or SVP64Single) and an Illegal Instruction Trap raised.
  63
  64 *Hardware Architectural Note: Given that a "pre-classification" Decode Phase
  65 is required (identifying whether the Suffix - Defined Word - is
  66 Arithmetic/Logical, CR-op, Load/Store or Branch-Conditional), adding
  67 "UnVectorised" to this phase is not unreasonable.*
  68
  69 # New 64-bit Instruction Encoding spaces
  70
  71 **Proposal: Add new Section 1.6.5 to Book I**
  72
  73 The following seven new areas are defined within Primary Opcode 9 (EXT009)
  74 as a new 64-bit encoding space, alongside Primary Opcode 1
  75 (EXT1xx).
  76
  77 | 0-5 | 6 | 7 | 8-31  | 32|33-63|Description                        |
  78 |-----|---|---|-------|---|-----|-----------------------------------|
  79 | PO9 | 0 | x | xxxx  | 0 | xxxx|  `RESERVED2` (57-bit) |
  80 | PO9 | 0 | 0 | !zero | 1 | DWd | SVP64Single:EXT232-263, or `RESERVED3` |
  81 | PO9 | 0 | 0 | 0000  | 1 | DWd | Scalar EXT232-263               |
  82 | PO9 | 0 | 1 | nnnn  | 1 | DWd | SVP64:EXT232-263     |
  83 | PO9 | 1 | 0 | 0000  | x | xxxx| `RESERVED1` (32-bit) |
  84 | PO9 | 1 | 0 | !zero | n | DWd | SVP64Single:EXT000-063 or `RESERVED4` |
  85 | PO9 | 1 | 1 | nnnn  | n | DWd | SVP64:EXT000-063       |
  86
  87 Key:
  88
  89 * **x** - a `RESERVED` encoding. Illegal Instruction Trap must be raised
  90 * **n** - a specification-defined value
  91 * **!zero** - a non-zero specification-defined value
  92 * **DWd** - when including bit 32 is a "Defined Word" as explained in
  93   Book I Section 1.6 (Public v3.1 p11)
  94
  95 Note that for the future SVP64Single Encoding (currently RESERVED3 and 4)
  96 it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
  97 for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
  98 prohibition allows SVP64Single to share its Encoding space with Scalar
  99 EXT232-263 and Scalar EXT300-363.
 100
 101 Also that RESERVED1 and 2 are candidates for future Major opcode
 102 areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
 103 they may equally be allocated entirely differently.
 104
 105 *Architectural Resource Allocation Note: Similar to ARM's `MOVPRFX`
 106 instruction and the original x86 REP instruction, despite "influence" over
 107 the Suffix, the Suffix is entirely independent of the Prefix.  Therefore
 108 **under no circumstances** must different Defined Words (different from
 109 the same **Un-Prefixed** Defined Word) be allocated within any `EXT{z}`
 110 prefixed or unprefixed space for a given value of `z` of 0, 2 or 3: the
 111 results would be catastrophic.  Even if UnVectoriseable an instruction
 112 Defined Word space **must** have the exact same Instruction and exact same
 113 Instruction Encoding in all spaces being RESERVED (Illegal Instruction
 114 Trap if UnVectoriseable) or not be allocated at all.  This is required
 115 as an inviolate hard rule governing Primary Opcode 9 that may not be
 116 revoked under any circumstances. A useful way to think of this is that
 117 the Prefix Encoding is, like the 8086 REP instruction, an independent
 118 32-bit Defined Word. The only semi-exceptions are the Post-Increment
 119 Mode of LD/ST-Update and Vectorised Branch-Conditional.*
 120
 121 Note a particular consequence of the application of the above paragraph:
 122 due to the fact that the Prefix Encodings are independent, **by
 123 definition** two new Sandbox areas "come into being" in an **inviolate**
 124 manner (i.e.  they may not be called anything else, nor may they
 125 be revoked rescinded removed or recalled), named `SVP64:EXT022` and
 126 `SVP64Single:EXT022`.  The **only way** that these two new areas may be
 127 revoked is if EXT022 itself is revoked.  **All and any** re-definitions
 128 modifications enhancements clarifications that apply to EXT022 **also
 129 apply to these two new areas** because due to the Prefixes being
 130 independent Defined Words the three areas are actually one and the same
 131 area, just as *all* Scalar Defined Words are.
 132
 133 Encoding spaces and their potential are illustrated:
 134
 135 | Encoding |Available bits|Scalar|Vectoriseable | SVP64Single  |PO1-Prefixable |
 136 |----------|--------------|------|--------------|--------------|---------------|
 137 |EXT000-063| 32           | yes  | yes          |yes           |yes            |
 138 |EXT100-163| 64           | yes  | no           |no            |not twice      |
 139 |RESERVED2 | 57           | N/A  |not applicable|not applicable|not applicable |
 140 |EXT232-263| 32           | yes  | yes          |yes           |no             |
 141 |RESERVED1 | 32           | N/A  | no           |no            |no             |
 142
 143 Notes:
 144
 145 * **PO9**-PO1 Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
 146   thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
 147   on top of an SVP64 prefix which is 32-bit on top of a Defined Word
 148   and the complexity at the Decoder becomes too great for High
 149   Performance Multi-Issue systems.
 150 * There is however no reason why PO9-PO1 (EXT901?) as an entirely new RESERVED
 151   64-bit Encoding
 152   should not be permitted as long as it is clearly marked as UnVectoriseable.
 153 * PO1-**PO9** Prefixed-Prefixed (96-bit) instructions are also prohibited
 154   for the same reason: Multi-Issue Decode complexity is too great.
 155 * There is however no reason why PO1-PO9 (EXT109) as an entirely new RESERVED
 156   64-bit Encoding
 157   should not be permitted as long as it is clearly marked as UnVectoriseable.
 158 * EXT100-163 instructions (PO1-Prefixed) are also prohibited from being
 159   double-PO1-prefixed (not twice prefixed)
 160 * RESERVED2 presently remains unallocated as of yet and therefore its
 161   potential is not yet defined (Not Applicable).
 162 * RESERVED1 is also unallocated at present, but it is known in advance
 163   that the area is UnVectoriseable and also cannot be Prefixed with
 164   SVP64Single.
 165 * Considerable care is needed both on Architectural Resource Allocation
 166   as well as instruction design itself. All new Scalar instructions automatically
 167   and inherently must be designed taking their Vectoriseable potential into
 168   consideration *including VSX* in future.
 169 * Once an instruction is allocated
 170   in an UnVectoriseable area it can never be Vectorised without providing
 171   an entirely new Encoding.
 172
 173 [[!tag standards]]
 174
 175 --------
 176
 177 \newpage{}
 178