openpower/sv/cr_ops.mdwn

   1 [[!tag standards]]
   2 # Condition Register SVP64 Operations
   3
   4 **DRAFT STATUS**
   5
   6 Links:
   7
   8 * <https://bugs.libre-soc.org/show_bug.cgi?id=687>
   9 * [[svp64]]
  10 * [[sv/branches]]
  11 * [[sv/cr_int_predication]]
  12 * [[openpower/isa/sprset]]
  13 * [[openpower/isa/condition]]
  14 * [[openpower/isa/comparefixed]]
  15
  16 Condition Register Fields are only 4 bits wide: this presents some
  17 interesting conceptual challenges for SVP64, which was designed
  18 primarily for vectors of arithmetic and logical operations. However
  19 if predicates may be bits of CR Fields it makes sense to extend
  20 SVP64 to cover CR Operations.
  21
  22 Element width however is clearly meaningless for a 4-bit
  23 collation of Conditions, EQ LT GE SO. Likewise, arithmetic saturation
  24 (an important part of Arithmetic SVP64)
  25 has no meaning. An alternative Mode Format is required, and given that elwidths are meaningless for CR Fields
  26 the bits in SVP64 `RM` may be used for other purposes.
  27
  28 This alternative mapping **only** applies to instructions that **only**
  29 reference a CR Field or CR bit as the sole exclusive result. This section
  30 **does not** apply to instructions which primarily produce arithmetic
  31 results that also, as an aside, produce a corresponding
  32 CR Field (such as when Rc=1).
  33 Instructions that involve Rc=1 are definitively arithmetic in nature,
  34 where the corresponding Condition Register Field can be considered to
  35 be a "co-result". Such CR Field "co-result" arithmeric operations
  36 are firmly out of scope for
  37 this section.
  38
  39 * Examples of v3.0B instructions to which this section does
  40   apply is
  41   - `mfcr` and `cmpi` (3 bit operands) and
  42   - `crnor` and `crand` (5 bit operands).
  43 * Examples to which this section does **not** apply include
  44   `fadds.` and `subf.` which both produce arithmetic results
  45   (and a CR Field co-result).
  46
  47 The CR Mode Format still applies to `sv.cmpi` because despite
  48 taking a GPR as input, the output from the Base Scalar v3.0B `cmpi`
  49 instruction is purely to a Condition Register Field.
  50
  51 Other modes are still applicable and include:
  52
  53 * **Data-dependent fail-first**.
  54   useful to truncate VL based on
  55   analysis of a Condition Register result bit.
  56 * **Scalar and parallel reduction**.
  57   Reduction is useful
  58 for analysing a Vector of Condition Register Fields
  59 and reducing it to one
  60 single Condition Register Field.
  61
  62 Predicate-result unfortunately does not make any sense because
  63 when Rc=1 a co-result is created (a CR Field). Testing the co-result
  64 allows the decision to be made to store or not store the main
  65 result, and unfortunately for CR Ops the CR Field result *is*
  66 the main result.
  67
  68 # Format
  69
  70 SVP64 RM `MODE` (includes `ELWIDTH_SRC` bits) for CR-based operations:
  71
  72 | 6 | 7 | 19-20 |  21 | 22   23 |  description     |
  73 | - | - | ----- | --- |---------|----------------- |
  74 |sz |SNZ| 0 RG  |   0 | dz  /   | normal mode                      |
  75 |sz |SNZ| 0 RG  |   1 | 0   /   | scalar reduce mode (mapreduce), SUBVL=1 |
  76 |zz |SNZ| 0 RG  |   1 | 1   /   | parallel reduce mode (mapreduce), SUBVL=1 |
  77 |sz |SNZ| 0 RG  |   1 | SVM /   | subvector reduce mode, SUBVL>1   |
  78 |sz |SNZ| 1 VLI | inv |  CR-bit | Ffirst 3-bit mode      |
  79 |sz |SNZ| 1 VLI | inv |  dz /   | Ffirst 5-bit mode       |
  80
  81 Fields:
  82
  83 * **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.
  84 * **zz** set both sz and dz equal to this flag
  85 * **SNZ** when sz=1 and SNZ=1 a value "1" is put in place of zeros when
  86   the predicate bit is clear (on both source and destination masks)
  87 * **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)
  88 * **RG** inverts the Vector Loop order (VL-1 downto 0) rather
  89 than the normal 0..VL-1
  90 * **SVM** sets "subvector" reduce mode
  91 * **VLi** VL inclusive: in fail-first mode, the truncation of
  92   VL *includes* the current element at the failure point rather
  93   than excludes it from the count.
  94
  95 # Data-dependent fail-first on CR operations
  96
  97 The principle of data-dependent fail-first is that if, during
  98 the course of sequentially evaluating an element's Condition Test,
  99 one such test is encountered which fails,
 100 then VL (Vector Length) is truncated at that point. In the case
 101 of Arithmetic SVP64 Operations the Condition Register Field generated from
 102 Rc=1 is used as the basis for the truncation decision.
 103 However with CR-based operations that CR Field result to be
 104 tested is provided
 105 *by the operation itself*.
 106
 107 Data-dependent SVP64 Vectorised Operations involving the creation or
 108 modification of a CR can require an extra two bits, which are not available
 109 in the compact space of the SVP64 RM `MODE` Field. With the concept of element
 110 width overrides being meaningless for CR Fields it is possible to use the
 111 `ELWIDTH` field for alternative purposes.
 112
 113 Condition Register based operations such as `sv.mfcr` and `sv.crand` can thus
 114 be made more flexible.  However the rules that apply in this section
 115 also apply to future CR-based instructions.
 116
 117 There are two primary different types of CR operations:
 118
 119 * Those which have a 3-bit operand field (referring to a CR Field)
 120 * Those which have a 5-bit operand (referring to a bit within the
 121    whole 32-bit CR)
 122
 123 Examining these two types it is observed that the
 124 difference may be considered to be that the 5-bit variant
 125 *already* provides the
 126 prerequisite information about which CR Field bit (EQ, GE, LT, SO) is to
 127 be operated on by the instruction.
 128 Thus, logically, we may set the following rule:
 129
 130 * When a 5-bit CR Result field is used in an instruction, the
 131   5-bit variant of Data-Dependent Fail-First
 132   must be used. i.e. the bit of the CR field to be tested is
 133   the one that has just been modified (created) by the operation.
 134 * When a 3-bit CR Result field is used the 3-bit variant
 135   must be used, providing as it does the missing `CRbit` field
 136   in order to select which CR Field bit of the result shall
 137   be tested (EQ, LE, GE, SO)
 138
 139 The reason why the 3-bit CR variant needs the additional CR-bit
 140 field should be obvious from the fact that the 3-bit CR Field
 141 from the base Power ISA v3.0B operation clearly does not contain
 142 and is missing the two CR Field Selector bits. Thus, these two
 143 bits (to select EQ, LE, GE or SO) must be provided in another
 144 way.
 145
 146 Examples of the former type:
 147
 148 * crand, cror, crnor. These all are 5-bit (BA, BB, BT). The bit
 149   to be tested against `inv` is the one selected by `BT`
 150 * mcrf. This has only 3-bit (BF, BFA). In order to select the
 151   bit to be tested, the alternative encoding must be used.
 152   With `CRbit` coming from the SVP64 RM bits 22-23 the bit
 153   of BF to be tested is identified.
 154
 155 Just as with SVP64 [[sv/branches]] there is the option to truncate
 156 VL to include the element being tested (`VLi=1`) and to exclude it
 157 (`VLi=0`).
 158
 159 Also just as with [[sv/normal]] fail-first VL cannot, unlike
 160 [[sv/ldst]], be set to an arbitrary value.  Deterministic behaviour
 161 is *required*.
 162
 163 # Reduction and Iteration
 164
 165 Bearing in mind as described in the [[svp64/appendix]] SVP64 Horizontal
 166 Reduction is a deterministic schedule on top of base Scalar v3.0 operations,
 167 the same rules apply to CR Operations, i.e. that programmers must
 168 follow certain conventions in order for an *end result* of a
 169 reduction to be achieved.  Unlike
 170 other Vector ISAs *there are no explicit reduction opcodes*
 171 in SVP64.
 172
 173 Due to these conventions only reduction on operations such as `crand`
 174 and `cror` are meaningful because these have Condition Register Fields
 175 as both input and output.
 176
 177 Also bear in mind that 'Reverse Gear' may be enabled, which can be
 178 used in combination with overlapping CR operations to iteratively accumulate
 179 results.  Issuing a `sv.crand` operation for example with `BA`
 180 differing from `BB` by one Condition Register Field would
 181 result in a cascade effect, where the first-encountered CR Field
 182 would set the result to zero, and also all subsequent CR Field
 183 elements thereafter:
 184
 185     # sv.crand/mr/rg CR4.ge.v, CR5.ge.v, CR4.ge.v
 186     for i in VL-1 downto 0 # reverse gear
 187          CR[4+i].ge &= CR[5+i].ge
 188
 189 # Unusual and quirky CR operations
 190
 191 ## cmp and other compare ops
 192
 193 `cmp` and `cmpi` etc take GPRs as sources and create a CR Field as a result.
 194
 195     cmpli BF,L,RA,UI
 196     cmpeqb BF,RA,RB
 197
 198 With `ELWIDTH` applying to the source operands this is perfectly fine.
 199
 200 ## crweird operations
 201
 202 There are 4 weird CR-GPR operations and one reasonable one in
 203 the [[cr_int_predication]] set:
 204
 205 * crrweird
 206 *       mtcrweird
 207 *       crweirder
 208 *       crweird
 209 * mcrfm - reasonably normal and referring to CR Fields for src and dest.
 210