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` (3 bit operands) and
  42   - `crnor` and `cmpi` (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` bits) for CR-based operations:
  71
  72 | 4 | 5 | 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 |sz |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 * **SNZ** when sz=1 and SNZ=1 a value "1" is put in place of zeros when
  85   the predicate bit is clear.
  86 * **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)
  87 * **RG** inverts the Vector Loop order (VL-1 downto 0) rather
  88 than the normal 0..VL-1
  89 * **SVM** sets "subvector" reduce mode
  90 * **VLi** VL inclusive: in fail-first mode, the truncation of
  91   VL *includes* the current element at the failure point rather
  92   than excludes it from the count.
  93
  94 # Data-dependent fail-first on CR operations
  95
  96 The principle of data-dependent fail-first is that if, during
  97 the course of sequentially evaluating an element's Condition Test,
  98 one such test is encountered which fails,
  99 then VL (Vector Length) is truncated at that point. In the case
 100 of Arithmetic SVP64 Operations the Condition Register Field generated from
 101 Rc=1 is used as the basis for the truncation decision.
 102 However with CR-based operations that CR Field result to be
 103 tested is provided
 104 *by the operation itself*.
 105
 106 Data-dependent SVP64 Vectorised Operations involving the creation or
 107 modification of a CR can require an extra two bits, which are not available
 108 in the compact space of the SVP64 RM `MODE` Field. With the concept of element
 109 width overrides being meaningless for CR Fields it is possible to use the
 110 `ELWIDTH` field for alternative purposes.
 111
 112 Condition Register based operations such as `sv.mfcr` and `sv.crand` can thus
 113 be made more flexible.  However the rules that apply in this section
 114 also apply to future CR-based instructions.
 115
 116 There are two primary different types of CR operations:
 117
 118 * Those which have a 3-bit operand field (referring to a CR Field)
 119 * Those which have a 5-bit operand (referring to a bit within the
 120    whole 32-bit CR)
 121
 122 Examining these two types it is observed that the
 123 difference may be considered to be that the 5-bit variant
 124 *already* provides the
 125 prerequisite information about which CR Field bit (EQ, GE, LT, SO) is to
 126 be operated on by the instruction.
 127 Thus, logically, we may set the following rule:
 128
 129 * When a 5-bit CR Result field is used in an instruction, the
 130   5-bit variant of Data-Dependent Fail-First
 131   must be used. i.e. the bit of the CR field to be tested is
 132   the one that has just been modified (created) by the operation.
 133 * When a 3-bit CR Result field is used the 3-bit variant
 134   must be used, providing as it does the missing `CRbit` field
 135   in order to select which CR Field bit of the result shall
 136   be tested (EQ, LE, GE, SO)
 137
 138 The reason why the 3-bit CR variant needs the additional CR-bit
 139 field should be obvious from the fact that the 3-bit CR Field
 140 from the base Power ISA v3.0B operation clearly does not contain
 141 and is missing the two CR Field Selector bits. Thus, these two
 142 bits (to select EQ, LE, GE or SO) must be provided in another
 143 way.
 144
 145 Examples of the former type:
 146
 147 * crand, cror, crnor. These all are 5-bit (BA, BB, BT). The bit
 148   to be tested against `inv` is the one selected by `BT`
 149 * mcrf. This has only 3-bit (BF, BFA). In order to select the
 150   bit to be tested, the alternative encoding must be used.
 151   With `CRbit` coming from the SVP64 RM bits 22-23 the bit
 152   of BF to be tested is identified.
 153
 154 Just as with SVP64 [[sv/branches]] there is the option to truncate
 155 VL to include the element being tested (`VLi=1`) and to exclude it
 156 (`VLi=0`).
 157
 158 Also just as with [[sv/normal]] fail-first VL cannot, unlike
 159 [[sv/ldst]], be set to an arbitrary value.  Deterministic behaviour
 160 is *required*.
 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.  Unlike
 169 other Vector ISAs *there are no explicit reduction opcodes*
 170 in SVP64.
 171
 172 Due to these conventions only reduction on operations such as `crand`
 173 and `cror` are meaningful because these have Condition Register Fields
 174 as both input and output.
 175
 176 Also bear in mind that 'Reverse Gear' may be enabled, which can be
 177 used in combination with overlapping CR operations to iteratively accumulate
 178 results.  Issuing a `sv.crand` operation for example with `BA`
 179 differing from `BB` by one Condition Register Field would
 180 result in a cascade effect, where the first-encountered CR Field
 181 would set the result to zero, and also all subsequent CR Field
 182 elements thereafter:
 183
 184     # sv.crand/mr/rg CR4.ge.v, CR5.ge.v, CR4.ge.v
 185     for i in VL-1 downto 0 # reverse gear
 186          CR[4+i].ge &= CR[5+i].ge
 187