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