openpower/sv/cr_ops.mdwn

   1 [[!tag standards]]
   2 # Condition Register SVP64 Operations
   3
   4 Links:
   5
   6 * <https://bugs.libre-soc.org/show_bug.cgi?id=687>
   7 * [[svp64]]
   8 * [[sv/branches]]
   9 * [[openpower/isa/sprset]]
  10 * [[openpower/isa/condition]]
  11 * [[openpower/isa/comparefixed]]
  12
  13 Condition Register Fields are only 4 bits wide: this presents some
  14 interesting conceptual challenges for SVP64, particularly with respect to element
  15 width (which is clearly meaningless for a 4-bit
  16 collation of Conditions, EQ LT GE SO). Likewise, arithmetic saturation
  17 (an important part of Arithmetic SVP64)
  18 has no meaning. Additionally, extra modes are required that only make
  19 sense for Vectorised CR Operations. Consequently an alternative Mode Format is required.
  20
  21 This alternative mapping **only** applies to instructions that **only**
  22 reference a CR Field or CR bit as the sole exclusive result. This section
  23 **does not** apply to instructions which primarily produce arithmetic
  24 results that also, as an aside, produce a corresponding
  25 CR Field (such as when Rc=1).
  26 Instructions that involve Rc=1 are definitively arithmetic in nature,
  27 where the corresponding Condition Register Field can be considered to
  28 be a "co-result". Such CR Field "co-result" arithmeric operations
  29 are firmly out of scope for
  30 this section.
  31
  32 * Examples of v3.0B instructions to which this section does
  33   apply is
  34   - `mfcr` (3 bit operands) and
  35   - `crnor` and `cmpi` (5 bit operands).
  36 * Examples to which this section does **not** apply include
  37   `fadds.` and `subf.` which both produce arithmetic results
  38   (and a CR Field co-result).
  39
  40 The CR Mode Format still applies to `sv.cmpi` because despite
  41 taking a GPR as input, the output from the Base Scalar v3.0B `cmpi`
  42 instruction is purely to a Condition Register Field.
  43
  44 Other modes are still applicable and include:
  45
  46 * **Data-dependent fail-first**.
  47   useful to truncate VL based on
  48   analysis of a Condition Register result bit.
  49 * **Scalar and parallel reduction**.
  50   Reduction is useful
  51 for analysing a Vector of Condition Register Fields
  52 and reducing it to one
  53 single Condition Register Field.
  54 * **Predicate-result**.
  55   An augmentation to predication in that only elements which pass a test
  56 on the result carried out *by the instruction itself*
  57 will end up actually being modified. This is in effect the same
  58 as ANDing the Condition Test with the destination predicate
  59 mask (hence the name, "predicate-result").
  60
  61 Predicate-result is a particularly powerful strategic mode
  62 in that it is the interaction of a source predicate, destination predicate,
  63 input operands *and* the output result, all combining to influence
  64 what actually goes into the Condition Register File. Given that
  65 predicates may themselves be Condition Registers it can be seen that
  66 there could potentially be up to **six** CR Fields involved in
  67 the execution of Predicate-result Mode.
  68
  69 SVP64 RM `MODE` (includes `ELWIDTH` bits) for CR-based operations:
  70
  71 | 4 | 5 | 19-20 |  21 | 22   23 |  description     |
  72 | - | - | ----- | --- |---------|----------------- |
  73 |sz |SNZ| 00    |   0 |  dz  /  | normal mode                      |
  74 |sz |SNZ| 00    |   1 | 0  RG   | scalar reduce mode (mapreduce), SUBVL=1 |
  75 |sz |SNZ| 00    |   1 | 1   /   | parallel reduce mode (mapreduce), SUBVL=1 |
  76 |sz |SNZ| 00    |   1 | SVM RG  | subvector reduce mode, SUBVL>1   |
  77 |sz |SNZ| 01/10 | inv |  CR-bit | Ffirst 3-bit mode      |
  78 |sz |SNZ| 01/10 | inv |  dz /   | Ffirst 5-bit mode       |
  79 |sz |SNZ| 11    | inv | CR-bit  |  3-bit pred-result CR sel |
  80 |sz |SNZ| 11    | inv | dz  /   |  5-bit pred-result z/nonz |
  81
  82 `VLI=0` when bits 19-20=0b01.
  83 `VLI=1` when bits 19-20=0b10.
  84
  85 Fields:
  86
  87 * **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.
  88 * **SNZ** when sz=1 and SNZ=1 a value "1" is put in place of zeros when
  89   the predicate bit is clear.
  90 * **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)
  91 * **RG** inverts the Vector Loop order (VL-1 downto 0) rather
  92 than the normal 0..VL-1
  93 * **SVM** sets "subvector" reduce mode
  94 * **VLi** VL inclusive: in fail-first mode, the truncation of
  95   VL *includes* the current element at the failure point rather
  96   than excludes it from the count.
  97
  98 # Data-dependent fail-first on CR operations
  99
 100 The principle of data-dependent fail-first is that if, during
 101 the course of sequentially evaluating an element's Condition Test,
 102 one such test is encountered which fails,
 103 then VL (Vector Length) is truncated at that point. In the case
 104 of Arithmetic SVP64 Operations the Condition Register Field generated from
 105 Rc=1 is used as the basis for the truncation decision.
 106 However with CR-based operations that CR Field result to be
 107 tested is provided
 108 *by the operation itself*.
 109
 110 Data-dependent SVP64 Vectorised Operations involving the creation or
 111 modification of a CR can require an extra two bits, which are not available
 112 in the compact space of the SVP64 RM `MODE` Field. With the concept of element
 113 width overrides being meaningless for CR Fields it is possible to use the
 114 `ELWIDTH` field for alternative purposes.
 115
 116 Condition Register based operations such as `sv.mfcr` and `sv.crand` can thus
 117 be made more flexible.  However the rules that apply in this section
 118 also apply to future CR-based instructions.
 119
 120 There are two primary different types of CR operations:
 121
 122 * Those which have a 3-bit operand field (referring to a CR Field)
 123 * Those which have a 5-bit operand (referring to a bit within the
 124    whole 32-bit CR)
 125
 126 Examining these two types it is observed that the
 127 difference may be considered to be that the 5-bit variant
 128 *already* provides the
 129 prerequisite information about which CR Field bit (EQ, GE, LT, SO) is to
 130 be operated on by the instruction.
 131 Thus, logically, we may set the following rule:
 132
 133 * When a 5-bit CR Result field is used in an instruction, the
 134   5-bit variant of Data-Dependent Fail-First
 135   must be used. i.e. the bit of the CR field to be tested is
 136   the one that has just been modified (created) by the operation.
 137 * When a 3-bit CR Result field is used the 3-bit variant
 138   must be used, providing as it does the missing `CRbit` field
 139   in order to select which CR Field bit of the result shall
 140   be tested (EQ, LE, GE, SO)
 141
 142 The reason why the 3-bit CR variant needs the additional CR-bit
 143 field should be obvious from the fact that the 3-bit CR Field
 144 from the base Power ISA v3.0B operation clearly does not contain
 145 and is missing the two CR Field Selector bits. Thus, these two
 146 bits (to select EQ, LE, GE or SO) must be provided in another
 147 way.
 148
 149 Examples of the former type:
 150
 151 * crand, cror, crnor. These all are 5-bit (BA, BB, BT). The bit
 152   to be tested against `inv` is the one selected by `BT`
 153 * mcrf. This has only 3-bit (BF, BFA). In order to select the
 154   bit to be tested, the alternative encoding must be used.
 155   With `CRbit` coming from the SVP64 RM bits 22-23 the bit
 156   of BF to be tested is identified.
 157
 158 Just as with SVP64 [[sv/branches]] there is the option to truncate
 159 VL to include the element being tested (`VLi=1`) and to exclude it
 160 (`VLi=0`).
 161
 162 # Reduction and Iteration
 163
 164 Bearing in mind as described in the [[svp64/appendix]] SVP64 Horizontal
 165 Reduction is a deterministic schedule on top of base Scalar v3.0 operations,
 166 the same rules apply to CR Operations, i.e. that programmers must
 167 follow certain conventions in order for an *end result* of a
 168 reduction to be achieved.  *There are no explicit reduction opcodes*
 169 in SVP64.
 170
 171 Due to these conventions only reduction on operations such as `crand`
 172 and `cror` are meaningful because these have Condition Register Fields
 173 as both input and output.
 174
 175 Also bear in mind that 'Reverse Gear' may be enabled, which can be
 176 used in combination with overlapping CR operations to iteratively accumulate
 177 results.  Issuing a `sv.crand` operation for example with `BA`
 178 differing from `BB` by one Condition Register Field would
 179 result in a cascade effect, where the first-encountered CR Field
 180 would set the result to zero, and also all subsequent CR Field
 181 elements thereafter:
 182
 183     # sv.crand/mr/rg CR4.ge.v, CR5.ge.v, CR4.ge.v
 184     for i in VL-1 downto 0 # reverse gear
 185          CR[4+i].ge &= CR[5+i].ge
 186
 187
 188
 189 # Predicate-result Condition Register operations
 190
 191 These are again slightly different compared to SVP64 arithmetic
 192 pred-result (described in [[svp64/appendix]]). The reason is that,
 193 again, for arithmetic operations the production of a CR Field when
 194 Rc=1 is a *co-result* accompanying the main arithmetic result, whereas
 195 for CR-based operations the CR Field (referred to by a 3-bit
 196 v3.0B base operand from e.g. `mfcr`) or CR bit (referred to by a 5-bit operand from e.g. `crnor`)
 197 *is* itself the explicit and sole result of the operation.
 198
 199 Therefore, logically, Predicate-result needs to be adapted to
 200 test the actual result of the CR-based instruction (rather than
 201 test the co-resultant CR when Rc=1, as is done for Arithmetic SVP64).
 202
 203     for i in range(VL):
 204         # predication test, skip all masked out elements.
 205         # skips when sz=0
 206         if sz=0 and predicate_masked_out(i):
 207              continue
 208         if predicate_masked_out(i):
 209            if 5bit mode:
 210               # only one bit of CR to update
 211               result = SNZ
 212            else
 213               # four copies of SNZ
 214               result = SNZ || SNZ || SNZ || SNZ
 215         else
 216            # result is to go into CR. may be a 4-bit CR Field
 217            # (3-bit mode) or just a single bit (5-bit mode)
 218            result = op(...)
 219         if 5bit mode:
 220            # if this CR op has 5-bit CR result operands
 221            # the single bit result is what must be tested
 222            to_test = result
 223         else
 224            # if however this is a 3-bit CR *field* result
 225            # then the bit to be tested must be selected
 226            to_test = result[CRbit]
 227         # now test CR, similar to branch
 228         if to_test != inv:
 229             continue # test failed: cancel store
 230         # result optionally stored
 231         update_CR(result)