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