openpower/sv/po9_encoding.mdwn

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