openpower/sv/propagation.mdwn

   1 [[!tag standards]]
   2
   3 # SV Context Propagation
   4
   5 [[!toc]]
   6
   7 Context Propagation is for a future version of SV
   8
   9 [[sv/svp64]] context is 24 bits long, and Swizzle is 12.  These
  10 are enormous and not sustainable as far as power consumption is
  11 concerned.  Also, there is repetition of the same contexts to different
  12 instructions. An idea therefore is to add a level of indirection that
  13 allows these contexts to be applied to multiple instructions.
  14
  15 The basic principle is to have a suite of 40 indices in a shift register
  16 that indicate one of seven Contexts shall be applied to upcoming 32 bit
  17 v3.0B instructions.  The Least Significant Index in the shift register is
  18 the one that is applied.  One of those indices is 0b000 which indicates
  19 "no prefix applied".
  20
  21 A special instruction in an svp64 context takes a copy of the `RM[0..23]`
  22 bits, alongside a 21 bit suite that indicates up to 20 32 bit instructions
  23 will have that `RM` applied to them, as well as an index to associate
  24 with the `RM`.  If there are already indices set within the shift register
  25 then the new entries are placed after the end of the highest-indexed one.
  26
  27 | 0.5|6.8  | 9.10|11.31|  name   |
  28 | -- | --- | --- | --- | ------- |
  29 | OP |     | MMM |     | ?-Form  |
  30 | OP | idx | 000 | imm |         |
  31
  32 Three different types of contexts are available so far: svp64 RM and
  33 swizzle. Their format is as follows when stored in SPRs:
  34
  35 | 0..3 | 4..7   | 8........31 |  name     |
  36 | ---- | ----   | ----------- | --------- |
  37 | 0000 | 0000   | `RM[0:23]`  |  svp64 RM |
  38 | 0001 | 0 mask | swiz1 swiz2 |  swizzle  |
  39 | 0010 | brev   | sh0-3 ms0-3 |  Remap    |
  40
  41
  42 There are 4 64 bit SPRs used for storing Context, and the data is stored
  43 as follows:
  44
  45 * 7 32 bit contexts are stored, each indexed from 0b001 to 0b111,
  46   2 per 64 bit SPR and 1 in the 4th.
  47 * Starting from bit 32 of the 4th SPR, in batches of 40 bits the Shift
  48   Registers are stored.
  49
  50 When each LSB is nonzero in any one of the seven Shift Registers
  51 the corresponding Contexts are looked up and merged (ORed) together.
  52 Contexts for different purposes however may not be mixed: an illegal
  53 instruction is raised if this occurs.
  54
  55 The reason for merging the contexts is so that different aspects may be
  56 applied.  For example some `RM` contexts may indicate that predication
  57 is to be applied to an instruction whilst another context may contain
  58 the svp64 Mode.  Combining the two allows the predication aspect to be
  59 merged and shared, making for better packing.
  60
  61 These changes occur on a precise schedule: compilers should not have
  62 difficulties statically allocating the Context Propagation, as long
  63 as certain conventions are followed, such as avoidance of allowing the
  64 context to propagate through branches used by more than one incoming path,
  65 and variable-length loops.
  66
  67 Loops, clearly, because if the setup of the shift registers does
  68 not precisely match the number of instructions, the meaning of those
  69 instructions will change as the bits in the shift registers run out!
  70 However if the loops are of fixed size and small enough (40 instructions
  71 maximum) then it is perfectly reasonable to insert repeated patterns into
  72 the shift registers, enough to cover all the loops.  Ordinarily however
  73 the use of the Context Propagation instructions should be inside the
  74 loop and it is the responsibility of the compiler and assembler writer
  75 to ensure that the shift registers reach zero before any loop jump-back
  76 point.
  77
  78 ## Pseudocode:
  79
  80 The internal data structures need not precisely match the SPRs.  Here are
  81 some internal datastructures:
  82
  83     bit sreg[7][40] # seven 40 bit shift registers
  84     bit context[7][24]   # seven contexts
  85     int sregoffs[7] # indicator where last bits were placed
  86
  87 The Context Propagation instruction then inserts bits into the selected
  88 stream:
  89
  90     count = 20-count_trailing_zeros(imm)
  91     context[idx] = new_context
  92     start = sregoffs[idx]
  93     sreg[idx][start:start+count] = imm[0:count]
  94     sregoffs[idx] += count
  95
  96 With each shift register being maintained independently the new bits are
  97 dropped in where the last ones end.  To get which one is to be applied
  98 is as follows:
  99
 100     apply_context
 101     for i in range(7):
 102         if sreg[i][0]:
 103             apply_context |= context[i]
 104         sreg[i] = sreg[i] >> 1
 105         sregoffs[i] -= 1
 106
 107 Note that it is the LSB that says which context is to be applied.
 108
 109 # Swizzle Propagation
 110
 111 Swizzle Contexts follow the same schedule except that there is a mask
 112 for specifying to which registers the swizzle is to be applied, and
 113 there is only 17 bit suite to indicate the instructions to which the
 114 swizzle applies.
 115
 116 The bits in rhe svp64 `RM` field are interpreted as a pair of 12 bit
 117 swizzles
 118
 119 | 0.5| 6.8 | 9.11| 12.14 | 15.31 |  name   |
 120 | -- | --- | --- | ----- | ----- | ------- |
 121 | OP |     | MMM | mask  |       | ?-Form  |
 122 | OP | idx | 001 | mask  |  imm  |         |
 123
 124 Note however that it is only svp64 encoded instructions to which swizzle
 125 applies, so Swizzle Shift Registers only activate (and shift down)
 126 on svp64 instructions. *This includes Context-propagated ones!*
 127
 128 The mask is encoded as follows:
 129
 130 * bit 0 indicates that src1 is swizzled
 131 * bit 1 indicates that src2 is swizzled
 132 * bit 2 indicates that src3 is swizzled
 133
 134 When the compiler creates Swizzle Contexts it is important to recall
 135 that the Contexts will be ORed together. Thus one Context may specify
 136 a mask whilst the other Context specifies the swizzles: ORing different
 137 mask contexts with different swizzle Contexts allows more combinations
 138 than would normally fit into seven Contexts.
 139
 140 More than one bit is permitted to be set in the mask: swiz1 is applied
 141 to the first src operand specified by the mask, and swiz2 is applied to
 142 the second.
 143
 144 # 2D/3D Matrix Remap
 145
 146 *Based on the old version [[simple_v_extension/remap]], the Shape CSRs
 147 remain the same as does the algorithm that performs the remapping*.
 148
 149 Remap allows up to four Vectors (all four arguments of `fma` for example)
 150 to be algorithmically arbitrarily remapped via 1D, 2D or 3D reshaping.
 151
 152 Vectors may be remapped such that Matrix multiply of any arbitrary size
 153 is performed in one Vectorised `fma` instruction as long as the total
 154 number of elements is less than 64 (maximum for VL).
 155
 156 Additionally it may be used to perform "zipping" and "unzipping" of
 157 elements in a regular fashion of any arbitrary size and depth: RGB
 158 or Audio channel data may be split into separate contiguous lanes of
 159 registers, for example.
 160
 161 There are four possible Shapes.  Unlike swizzle contexts this one requires
 162 he external remap Shape SPRs because the state information is too large
 163 to fit into the Context itself.  Thus the Remap Context says which Shapes
 164 apply to which registers.
 165
 166 The instruction format is the same as `RM` and thus uses 21 bits of
 167 immediate, 29 of which are dropped into the indexed Shift Register
 168
 169 | 0.5| 6.8 | 9.10| 11.14 | 15.31|  name   |
 170 | -- | --- | --- | ----  | ---- | ------- |
 171 | OP |     | MM  |       |      | ?-Form  |
 172 | OP | idx | 01  | brev  | imm  |         |
 173
 174 brev field, which also applied down to SUBVL elements (not to the whole
 175 vec2/3/4, that would be handled by swizzle reordering)
 176
 177 * bit 0 indicates that dest elements are byte-reversed
 178 * bit 1 indicates that src1 elements are byte-reversed
 179 * bit 2 indicates that src2 elements are byte-reversed
 180 * bit 3 indicates that src3 elements are byte-reversed
 181
 182 Again it is the 24 bit `RM` that is interpreted differently:
 183
 184 | 0...7 | 8....23 |
 185 | ----- | ------- |
 186 | sh0-3 | mask0-3 |
 187
 188 The shape indices 0-3 are numbered 0-3 whilst the masks are bitmasks
 189 that indicate src or dest to which the associated shape (0-3) is to
 190 be applied.  A zero mask indicates that the Shape is not to be applied.
 191 Note that whilst the masks are unary encoded the Shape indices sh0-3
 192 are not: this must be taken into consideration when ORing occurs.
 193
 194 The mask is encoded as follows:
 195
 196 * bit 0 indicates that dest is reshaped
 197 * bit 1 indicates that src1 is reshaped
 198 * bit 2 indicates that src2 is reshaped
 199 * bit 3 indicates that src3 is reshaped