openpower/sv/po9_encoding.mdwn

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