openpower/sv/normal.mdwn

   1 [[!tag standards]]
   2
   3 # Normal SVP64 Modes, for Arithmetic and Logical Operations
   4
   5 * <https://bugs.libre-soc.org/show_bug.cgi?id=574>
   6 * <https://bugs.libre-soc.org/show_bug.cgi?id=558#c47>
   7 * [[svp64]]
   8
   9 Normal SVP64 Mode covers Arithmetic and Logical operations
  10 to provide suitable additional behaviour.  The Mode
  11 field is bits 19-23 of the [[svp64]] RM Field.
  12
  13 Table of contents:
  14
  15 [[!toc]]
  16
  17 # Mode
  18
  19 Mode is an augmentation of SV behaviour, providing additional
  20 functionality.  Some of these alterations are element-based (saturation), others involve post-analysis (predicate result) and others are Vector-based (mapreduce, fail-on-first).
  21
  22 [[sv/ldst]],
  23 [[sv/cr_ops]] and [[sv/branches]] are covered separately: the following
  24 Modes apply to Arithmetic and Logical SVP64 operations:
  25
  26 * **normal** mode is straight vectorisation.  no augmentations: the vector comprises an array of independently created results.
  27 * **ffirst** or data-dependent fail-on-first: see separate section.  the vector may be truncated depending on certain criteria.
  28   *VL is altered as a result*.
  29 * **sat mode** or saturation: clamps each element result to a min/max rather than overflows / wraps.  allows signed and unsigned clamping for both INT
  30 and FP.
  31 * **reduce mode**. a mapreduce is performed.  the result is a scalar.  a result vector however is required, as the upper elements may be used to store intermediary computations.  the result of the mapreduce is in the first element with a nonzero predicate bit.  see [[svp64/appendix]]
  32   note that there are comprehensive caveats when using this mode.
  33 * **pred-result** will test the result (CR testing selects a bit of CR and inverts it, just like branch conditional testing) and if the test fails it
  34 is as if the
  35 *destination* predicate bit was zero even before starting the operation.
  36 When Rc=1 the CR element however is still stored in the CR regfile, even if the test failed.  See appendix for details.
  37 * **Pack/Unpack** mode, only available when SUBVL is vec2/3/4, performs
  38 basic structure packing on sub-elements. Bits 4-5 (normally elwidth) are
  39 taken up as Pack/Unpack bits.
  40
  41 Note that ffirst and reduce modes are not anticipated to be high-performance in some implementations.  ffirst due to interactions with VL, and reduce due to it requiring additional operations to produce a result.  normal, saturate and pred-result are however inter-element independent and may easily be parallelised to give high performance, regardless of the value of VL.
  42
  43 The Mode table for Arithmetic and Logical operations
  44  is laid out as follows:
  45
  46 | 0-1 |  2  |  3   4  |  description              |
  47 | --- | --- |---------|-------------------------- |
  48 | 00  |   0 |  dz  sz | normal mode                      |
  49 | 00  |   1 | 0  RG   | scalar reduce mode (mapreduce), SUBVL=1 |
  50 | 00  |   1 | 1  /    | parallel reduce mode (mapreduce), SUBVL=1 |
  51 | 00  |   1 | SVM 0   | subvector reduce mode, SUBVL>1   |
  52 | 00  |   1 | SVM 1   | Pack/Unpack mode, SUBVL>1   |
  53 | 01  | inv | CR-bit  | Rc=1: ffirst CR sel              |
  54 | 01  | inv | VLi RC1 |  Rc=0: ffirst z/nonz |
  55 | 10  |   N | dz   sz |  sat mode: N=0/1 u/s |
  56 | 11  | inv | CR-bit  |  Rc=1: pred-result CR sel |
  57 | 11  | inv | zz  RC1 |  Rc=0: pred-result z/nonz |
  58
  59 Fields:
  60
  61 * **sz / dz**  if predication is enabled will put zeros into the dest (or as src in the case of twin pred) when the predicate bit is zero.  otherwise the element is ignored or skipped, depending on context.
  62 * **zz**: both sz and dz are set equal to this flag
  63 * **inv CR bit** just as in branches (BO) these bits allow testing of a CR bit and whether it is set (inv=0) or unset (inv=1)
  64 * **RG** inverts the Vector Loop order (VL-1 downto 0) rather
  65 than the normal 0..VL-1
  66 * **SVM** sets "subvector" reduce mode
  67 * **N** sets signed/unsigned saturation.
  68 * **RC1** as if Rc=1, stores CRs *but not the result*
  69 * **VLi** VL inclusive: in fail-first mode, the truncation of
  70   VL *includes* the current element at the failure point rather
  71   than excludes it from the count.
  72
  73 For LD/ST Modes, see [[sv/ldst]].  For Condition Registers
  74 see [[sv/cr_ops]].
  75 For Branch modes, see [[sv/branches]].
  76
  77 # Rounding, clamp and saturate
  78
  79 See [[av_opcodes]] for relevant opcodes and use-cases.
  80
  81 To help ensure that audio quality is not compromised by overflow,
  82 "saturation" is provided, as well as a way to detect when saturation
  83 occurred if desired (Rc=1). When Rc=1 there will be a *vector* of CRs,
  84 one CR per element in the result (Note: this is different from VSX which
  85 has a single CR per block).
  86
  87 When N=0 the result is saturated to within the maximum range of an
  88 unsigned value.  For integer ops this will be 0 to 2^elwidth-1. Similar
  89 logic applies to FP operations, with the result being saturated to
  90 maximum rather than returning INF, and the minimum to +0.0
  91
  92 When N=1 the same occurs except that the result is saturated to the min
  93 or max of a signed result, and for FP to the min and max value rather
  94 than returning +/- INF.
  95
  96 When Rc=1, the CR "overflow" bit is set on the CR associated with the
  97 element, to indicate whether saturation occurred.  Note that due to
  98 the hugely detrimental effect it has on parallel processing, XER.SO is
  99 **ignored** completely and is **not** brought into play here.  The CR
 100 overflow bit is therefore simply set to zero if saturation did not occur,
 101 and to one if it did.
 102
 103 Note also that saturate on operations that set OE=1 must raise an
 104 Illegal Instruction due to the conflicting use of the CR.so bit for
 105 storing if
 106 saturation occurred. Integer Operations that produce a Carry-Out (CA, CA32):
 107 these two bits will be `UNDEFINED` if saturation is also requested.
 108
 109 Note that the operation takes place at the maximum bitwidth (max of
 110 src and dest elwidth) and that truncation occurs to the range of the
 111 dest elwidth.
 112
 113 *Programmer's Note: Post-analysis of the Vector of CRs to find out if any given element hit
 114 saturation may be done using a mapreduced CR op (cror), or by using the
 115 new crrweird instruction with Rc=1, which will transfer the required
 116 CR bits to a scalar integer and update CR0, which will allow testing
 117 the scalar integer for nonzero.  see [[sv/cr_int_predication]]*
 118
 119 # Reduce mode
 120
 121 Reduction in SVP64 is similar in essence to other Vector Processing
 122 ISAs, but leverages the underlying scalar Base v3.0B operations.
 123 Thus it is more a convention that the programmer may utilise to give
 124 the appearance and effect of a Horizontal Vector Reduction. Due
 125 to the unusual decoupling it is also possible to perform
 126 prefix-sum in certain circumstances. Details are in the [[svp64/appendix]]
 127
 128 # Fail-on-first
 129
 130 Data-dependent fail-on-first has two distinct variants: one for LD/ST,
 131 the other for arithmetic operations (actually, CR-driven).  Note in each
 132 case the assumption is that vector elements are required appear to be
 133 executed in sequential Program Order, element 0 being the first.
 134
 135 * Data-driven (CR-driven) fail-on-first activates when Rc=1 or other
 136   CR-creating operation produces a result (including cmp).  Similar to
 137   branch, an analysis of the CR is performed and if the test fails, the
 138   vector operation terminates and discards all element operations at and
 139   above the current one, and VL is truncated to either
 140   the *previous* element or the current one, depending on whether
 141   VLi (VL "inclusive") is set.
 142
 143 Thus the new VL comprises a contiguous vector of results,
 144 all of which pass the testing criteria (equal to zero, less than zero).
 145
 146 The CR-based data-driven fail-on-first is "new" and not found in ARM
 147 SVE or RVV. At the same time it is "old" because it is almost
 148 identical to a generalised form of Z80's `CPIR` instruction.
 149 It is extremely useful for reducing instruction count,
 150 however requires speculative execution involving modifications of VL
 151 to get high performance implementations.  An additional mode (RC1=1)
 152 effectively turns what would otherwise be an arithmetic operation
 153 into a type of `cmp`.  The CR is stored (and the CR.eq bit tested
 154 against the `inv` field).
 155 If the CR.eq bit is equal to `inv` then the Vector is truncated and
 156 the loop ends.
 157 Note that when RC1=1 the result elements are never stored, only the CRs.
 158
 159 VLi is only available as an option when `Rc=0` (or for instructions
 160 which do not have Rc). When set, the current element is always
 161 also included in the count (the new length that VL will be set to).
 162 This may be useful in combination with "inv" to truncate the Vector
 163 to `exclude` elements that fail a test, or, in the case of implementations
 164 of strncpy, to include the terminating zero.
 165
 166 In CR-based data-driven fail-on-first there is only the option to select
 167 and test one bit of each CR (just as with branch BO).  For more complex
 168 tests this may be insufficient.  If that is the case, a vectorised crop
 169 such as crand, cror or [[sv/cr_int_predication]] crweirder may be used,
 170 and ffirst applied to the crop instead of to
 171 the arithmetic vector. Note that crops are covered by
 172 the [[sv/cr_ops]] Mode format.
 173
 174 Two extremely important aspects of ffirst are:
 175
 176 * LDST ffirst may never set VL equal to zero.  This because on the first
 177   element an exception must be raised "as normal".
 178 * CR-based data-dependent ffirst on the other hand **can** set VL equal
 179   to zero. This is the only means in the entirety of SV that VL may be set
 180   to zero (with the exception of via the SV.STATE SPR).  When VL is set
 181   zero due to the first element failing the CR bit-test, all subsequent
 182   vectorised operations are effectively `nops` which is
 183   *precisely the desired and intended behaviour*.
 184
 185 The second crucial aspect, compared to LDST Ffirst:
 186
 187 * LD/ST Failfirst may (beyond the initial first element
 188   conditions) truncate VL for any architecturally
 189   suitable reason.
 190 * CR-based data-dependent first on the other hand MUST NOT truncate VL
 191 arbitrarily to a length decided by the hardware: VL MUST only be
 192 truncated based explicitly on whether a test fails.
 193 This because it is a precise test on which algorithms
 194 will rely.
 195
 196 ## Data-dependent fail-first on CR operations (crand etc)
 197
 198 Operations that actually produce or alter CR Field as a result
 199 have their own SVP64 Mode, described
 200 in [[sv/cr_ops]]
 201
 202 # pred-result mode
 203
 204 This mode merges common CR testing with predication, saving on instruction
 205 count. Below is the pseudocode excluding predicate zeroing and elwidth
 206 overrides. Note that the pseudocode for [[sv/cr_ops]] is slightly different.
 207
 208     for i in range(VL):
 209         # predication test, skip all masked out elements.
 210         if predicate_masked_out(i):
 211              continue
 212         result = op(iregs[RA+i], iregs[RB+i])
 213         CRnew = analyse(result) # calculates eq/lt/gt
 214         # Rc=1 always stores the CR
 215         if Rc=1 or RC1:
 216             crregs[offs+i] = CRnew
 217         # now test CR, similar to branch
 218         if RC1 or CRnew[BO[0:1]] != BO[2]:
 219             continue # test failed: cancel store
 220         # result optionally stored but CR always is
 221         iregs[RT+i] = result
 222
 223 The reason for allowing the CR element to be stored is so that
 224 post-analysis of the CR Vector may be carried out.  For example:
 225 Saturation may have occurred (and been prevented from updating, by the
 226 test) but it is desirable to know *which* elements fail saturation.
 227
 228 Note that RC1 Mode basically turns all operations into `cmp`.  The
 229 calculation is performed but it is only the CR that is written. The
 230 element result is *always* discarded, never written (just like `cmp`).
 231
 232 Note that predication is still respected: predicate zeroing is slightly
 233 different: elements that fail the CR test *or* are masked out are zero'd.
 234
 235 # Pack/Unpack Mode
 236
 237 Structured Pack/Unpack is similar to VSX `vpack` and `vunpack` except
 238 generalised not only to a Schedule to be applied to any operation but
 239 also extended to vec2/3/4.
 240
 241 Setting this mode changes the meaning of bits 4-5 in `RM` from being
 242 `ELWIDTH` to a pair of Pack/Unpack bits.  Thus it is not possible
 243 to separately override source and destination elwidths at the same
 244 time as use Pack/Unpack: the `SRC_ELWIDTH` bits (6-7) must be used as
 245 both source and destination elwidth.
 246
 247 This was considered to be an acceptable
 248 compromise.  If separate elwidths are required and Pack/Unpack
 249 needed without needing to perform a widening or narrowing register
 250 move then [[sv/remap]] may be used: Matrix Mode may perform the
 251 same operation (but is more costly to set up).
 252 See [[sv/svp64/appendix]] for details on how Pack/Unpack
 253 is implemented.