1 # REMAP <a name="remap" />
4 * <https://bugs.libre-soc.org/show_bug.cgi?id=143> matrix multiply
5 * <https://bugs.libre-soc.org/show_bug.cgi?id=867> add svindex
6 * <https://bugs.libre-soc.org/show_bug.cgi?id=885> svindex in simulator
7 * <https://bugs.libre-soc.org/show_bug.cgi?id=911> offset svshape option
8 * <https://bugs.libre-soc.org/show_bug.cgi?id=864> parallel reduction
9 * <https://bugs.libre-soc.org/show_bug.cgi?id=930> DCT/FFT "strides"
10 * <https://bugs.libre-soc.org/show_bug.cgi?id=1155> bigmul (normal and carry-save)
11 * see [[sv/remap/appendix]] for examples and usage
12 * see [[sv/propagation]] for a future way to apply REMAP
13 * [[remap/discussion]]
16 REMAP is an advanced form of Vector "Structure Packing" that provides
17 hardware-level support for commonly-used *nested* loop patterns that would
18 otherwise require full inline loop unrolling. For more general reordering
19 an Indexed REMAP mode is available (a RISC-paradigm
20 abstracted analog to `xxperm`).
22 REMAP allows the usual sequential vector loop `0..VL-1` to be "reshaped"
23 (re-mapped) from a linear form to a 2D or 3D transposed form, or "offset"
24 to permit arbitrary access to elements, independently on each
25 Vector src or dest register. Up to four separate independent REMAPs may be applied
26 to the registers of any instruction.
28 A normal Vector Add (no Element-width Overrides):
32 GPR[RT+i] <= GPR[RA+i] + GPR[RB+i];
35 A Hardware-assisted REMAP Vector Add:
39 GPR[RT+remap1(i)] <= GPR[RA+remap2(i)] + GPR[RB+remap3(i)];
43 Indexed REMAP this is entirely Hardware-accelerated reordering and
44 consequently not costly in terms of register access for the Indices. It will however
45 place a burden on Multi-Issue systems but no more than if the equivalent
46 Scalar instructions were explicitly loop-unrolled without SVP64, and
47 some advanced implementations may even find the Deterministic nature of
48 the Scheduling to be easier on resources.
50 *Hardware note: in its general form, REMAP is quite expensive to set up, and on some
51 implementations may introduce latency, so should realistically be used
52 only where it is worthwhile. Given that even with latency the fact
53 that up to 127 operations can be Deterministically issued (from a single
54 instruction) it should be clear that REMAP should not be dismissed
55 for *possible* latency alone. Commonly-used patterns such as Matrix
56 Multiply, DCT and FFT have helper instruction options which make REMAP
59 There are five types of REMAP:
61 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
62 Matrix transpose and rotate. The Shapes are set up for an "Outer Product"
63 Matrix Multiply (a future variant may introduce Inner Product).
64 * **FFT/DCT**, with full triple-loop in-place support: limited to
66 * **Indexing**, for any general-purpose reordering, also includes
67 limited 2D reshaping as well as Element "offsetting".
68 * **Parallel Reduction**, for scheduling a sequence of operations
69 in a Deterministic fashion, in a way that may be parallelised,
70 to reduce a Vector down to a single value.
71 * **Parallel Prefix Sum**, implemented as a work-efficient Schedule,
72 has several key Computer Science uses. Again Prefix Sum is 100%
75 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
76 REMAP Schedules are 100% Deterministic **including Indexing** and are
77 designed to be incorporated in between the Decode and Issue phases,
78 directly into Register Hazard Management.
80 As long as the SVSHAPE SPRs
81 are not written to directly, Hardware may treat REMAP as 100%
82 Deterministic: all REMAP Management instructions take static
83 operands (no dynamic register operands)
84 with the exception of Indexed Mode, and even then
85 Architectural State is permitted to assume that the Indices
86 are cacheable from the point at which the `svindex` instruction
89 Further details on the Deterministic Precise-Interruptible algorithms
90 used in these Schedules is found in the [[sv/remap/appendix]].
92 *Future specification note: future versions of the REMAP Management instructions
93 will extend to EXT1xx Prefixed variants. This will overcome some of the limitations
94 present in the 32-bit variants of the REMAP Management instructions that at
95 present require direct writing to SVSHAPE0-3 SPRs. Additional
96 REMAP Modes may also be introduced at that time.*
98 ## Determining Register Hazards (hphint)
100 For high-performance (Multi-Issue, Out-of-Order) systems it is critical
101 to be able to statically determine the extent of Vectors in order to
102 allocate pre-emptive Hazard protection. The next task is to eliminate
103 masked-out elements using predicate bits, freeing up the associated
106 For non-REMAP situations `VL` is sufficient to ascertain early
107 Hazard coverage, and with SVSTATE being a high priority cached
108 quantity at the same level of MSR and PC this is not a problem.
110 The problems come when REMAP is enabled. Indexed REMAP must instead
111 use `MAXVL` as the earliest (simplest)
112 batch-level Hazard Reservation indicator (after taking element-width
113 overriding on the Index source into consideration),
114 but Matrix, FFT and Parallel Reduction must all use completely different
115 schemes. The reason is that VL is used to step through the total
116 number of *operations*, not the number of registers.
117 The "Saving Grace" is that all of the REMAP Schedules are 100% Deterministic.
119 Advance-notice Parallel computation and subsequent cacheing
120 of all of these complex Deterministic REMAP Schedules is
121 *strongly recommended*, thus allowing clear and precise multi-issue
122 batched Hazard coverage to be deployed, *even for Indexed Mode*.
123 This is only possible for Indexed due to the strict guidelines
124 given to Programmers.
126 In short, there exists solutions to the problem of Hazard Management,
127 with varying degrees of refinement possible at correspondingly
128 increasing levels of complexity in hardware.
130 A reminder: when Rc=1 each result register (element) has an associated
131 co-result CR Field (one per result element). Thus above when determining
132 the Write-Hazards for result registers the corresponding Write-Hazards for the
133 corresponding associated co-result CR Field must not be forgotten, *including* when
136 **Horizontal-Parallelism Hint**
138 To help further in reducing Hazards,
139 `SVSTATE.hphint` is an indicator to hardware of how many elements are 100%
140 fully independent. Hardware is permitted to assume that groups of elements
141 up to `hphint` in size need not have Register (or Memory) Hazards created
142 between them, including when `hphint > VL`, which greatly aids simplification of
143 Multi-Issue implementations.
145 If care is not taken in setting `hphint` correctly it may wreak havoc.
146 For example Matrix Outer Product relies on the innermost loop computations
147 being independent. If `hphint` is set to greater than the Outer Product
148 depth then data corruption is guaranteed to occur.
150 Likewise on FFTs it is assumed that each layer of the RADIX2 triple-loop
151 is independent, but that there is strict *inter-layer* Register Hazards.
152 Therefore if `hphint` is set to greater than the RADIX2 width of the FFT,
153 data corruption is guaranteed.
155 Thus the key message is that setting `hphint` requires in-depth knowledge
156 of the REMAP Algorithm Schedules, given in the Appendix.
158 ## REMAP area of SVSTATE SPR <a name="svstate_remap_area"> </>
160 The following bits of the SVSTATE SPR are used for REMAP:
163 |32:33|34:35|36:37|38:39|40:41| 42:46 | 62 |
164 | -- | -- | -- | -- | -- | ----- | ------ |
165 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
168 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
169 mi0-2 apply to RA, RB, RC respectively, as input registers, and
170 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
171 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
172 SVSHAPE is actively applied or not, and if so, to which registers.
174 * bit 4 of SVme indicates if mi0 is applied to source RA / FRA / BA / BFA / RT / FRT
175 * bit 3 of SVme indicates if mi1 is applied to source RB / FRB / BB
176 * bit 2 of SVme indicates if mi2 is applied to source RC / FRC / BC
177 * bit 1 of SVme indicates if mo0 is applied to result RT / FRT / BT / BF
178 * bit 0 of SVme indicates if mo1 is applied to result Effective Address / FRS / RS
179 (LD/ST-with-update has an implicit 2nd write register, RA)
181 The "persistence" bit if set will result in all Active REMAPs being applied
188 # svremap instruction <a name="svremap"> </a>
192 |0 |6 |11 |13 |15 |17 |19 |21 | 22:25 |26:31 |
193 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
194 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
196 * svremap SVme,mi0,mi1,mi2,mo0,mo1,pst
201 # registers RA RB RC RT EA/FRS SVSHAPE0-3 indices
202 SVSTATE[32:33] <- mi0
203 SVSTATE[34:35] <- mi1
204 SVSTATE[36:37] <- mi2
205 SVSTATE[38:39] <- mo0
206 SVSTATE[40:41] <- mo1
207 # enable bit for RA RB RC RT EA/FRS
208 SVSTATE[42:46] <- SVme
209 # persistence bit (applies to more than one instruction)
213 Special Registers Altered:
219 `svremap` establishes the connection between registers and SVSHAPE SPRs.
220 The bitmask `SVme` determines which registers have a REMAP applied, and mi0-mo1
221 determine which shape is applied to an activated register. the `pst` bit if
222 cleared indicated that the REMAP operation shall only apply to the immediately-following
223 instruction. If set then REMAP remains permanently enabled until such time as it is
224 explicitly disabled, either by `setvl` setting a new MAXVL, or with another
225 `svremap` instruction. `svindex` and `svshape2` are also capable of setting or
226 clearing persistence, as well as partially covering a subset of the capability of
227 `svremap` to set register-to-SVSHAPE relationships.
229 Programmer's Note: applying non-persistent `svremap` to an instruction that has
230 no REMAP enabled or is a Scalar operation will obviously have no effect but
231 the bits 32 to 46 will at least have been set in SVSTATE. This may prove useful
232 when using `svindex` or `svshape2`.
234 Hardware Architectural Note: when persistence is not set it is critically important
235 to treat the `svremap` and the immediately-following SVP64 instruction as an
236 indivisible fused operation.
237 *No state* is stored in the SVSTATE SPR in order to allow continuation should an
238 Interrupt occur between the two instructions. Thus, Interrupts must be prohibited
239 from occurring or other workaround deployed. When persistence is set this issue
242 It is critical to note that if persistence is clear then `svremap` is the *only* way
243 to activate REMAP on any given (following) instruction. If persistence is set however then
244 **all** SVP64 instructions go through REMAP as long as `SVme` is non-zero.
250 # SHAPE Remapping SPRs
252 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
253 which have the same format. It is possible to write directly to these
254 SPRs but it is recommended to use the Management instructions
255 `svshape`, `svshape2` or `svindex`.
257 When SHAPE is set entirely to zeros, remapping is
258 disabled: the register's elements are a linear (1D) vector.
260 |0:5 |6:11 | 12:17 | 18:20 | 21:23 |24:27 |28:29 |30:31| Mode |
261 |----- |----- | ------- | ------- | ------ |------|------ |---- | ----- |
262 |xdimsz|ydimsz| zdimsz | permute | invxyz |offset|skip |mode |Matrix |
263 |xdimsz|ydimsz|SVGPR | 11/ |sk1/invxy|offset|elwidth|0b00 |Indexed|
264 |xdimsz|mode | zdimsz | submode2| invxyz |offset|submode|0b01 |DCT/FFT|
265 | rsvd |rsvd |xdimsz | rsvd | invxyz |offset|submode|0b10 |Red/Sum|
266 | | | | | | | |0b11 |rsvd |
268 `mode` sets different behaviours (straight matrix multiply, FFT, DCT).
270 * **mode=0b00** sets straight Matrix Mode
271 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
272 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
273 * **mode=0b10** sets "Parallel Reduction or Prefix-Sum" Schedules.
275 *Architectural Resource Allocation note: the four SVSHAPE SPRs are best
276 allocated sequentially and contiguously in order that `sv.mtspr` may
277 be used. This is safe to do as long as `SVSTATE.SVme=0`*
279 ## Parallel Reduction / Prefix-Sum Mode
281 Creates the Schedules for Parallel Tree Reduction and Prefix-Sum
283 * **submode=0b00** selects the left operand index for Reduction
284 * **submode=0b01** selects the right operand index for Reduction
285 * **submode=0b10** selects the left operand index for Prefix-Sum
286 * **submode=0b11** selects the right operand index for Prefix-Sum
288 * When bit 0 of `invxyz` is set, the order of the indices
289 in the inner for-loop are reversed. This has the side-effect
290 of placing the final reduced result in the last-predicated element.
291 It also has the indirect side-effect of swapping the source
292 registers: Left-operand index numbers will always exceed
293 Right-operand indices.
294 When clear, the reduced result will be in the first-predicated
295 element, and Left-operand indices will always be *less* than
297 * When bit 1 of `invxyz` is set, the order of the outer loop
298 step is inverted: stepping begins at the nearest power-of two
299 to half of the vector length and reduces by half each time.
300 When clear the step will begin at 2 and double on each
303 **Parallel Prefix Sum**
305 This is a work-efficient Parallel Schedule that for example produces Trangular
306 or Factorial number sequences. Half of the Prefix Sum Schedule is near-identical
307 to Parallel Reduction. Whilst the Arithmetic mapreduce Mode (`/mr`) may achieve the same
308 end-result, implementations may only implement Mapreduce in serial form (or give
309 the appearance to Programmers of the same). The Parallel Prefix Schedule is
310 *required* to be implemented in such a way that its Deterministic Schedule may be
311 parallelised. Like the Reduction Schedule it is 100% Deterministic and consequently
312 may be used with non-commutative operations.
313 The Schedule Algorithm may be found in the [[sv/remap/appendix]]
315 **Parallel Reduction**
317 Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
318 (Power ISA v3.0B) operation is leveraged, unmodified, to give the
319 *appearance* and *effect* of Reduction. Parallel Reduction is not limited
320 to Power-of-two but is limited as usual by the total number of
321 element operations (127) as well as available register file size.
323 In Horizontal-First Mode, Vector-result reduction **requires**
324 the destination to be a Vector, which will be used to store
325 intermediary results, in order to achieve a correct final
328 Given that the tree-reduction schedule is deterministic,
329 Interrupts and exceptions
330 can therefore also be precise. The final result will be in the first
331 non-predicate-masked-out destination element, but due again to
332 the deterministic schedule programmers may find uses for the intermediate
333 results, even for non-commutative Defined Word-instruction operations.
334 Additionally, because the intermediate results are always written out
335 it is possible to service Precise Interrupts without affecting latency
336 (a common limitation of Vector ISAs implementing explicit
337 Parallel Reduction instructions, because their Architectural State cannot
338 hold the partial results).
340 When Rc=1 a corresponding Vector of co-resultant CRs is also
341 created. No special action is taken: the result *and its CR Field*
342 are stored "as usual" exactly as all other SVP64 Rc=1 operations.
344 Note that the Schedule only makes sense on top of certain instructions:
345 X-Form with a Register Profile of `RT,RA,RB` is fine because two sources
346 and the destination are all the same type. Like Scalar
347 Reduction, nothing is prohibited:
348 the results of execution on an unsuitable instruction may simply
349 not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
350 may be used, and whilst it is down to the Programmer to walk through the
351 process the Programmer can be confident that the Parallel-Reduction is
352 guaranteed 100% Deterministic.
354 Critical to note regarding use of Parallel-Reduction REMAP is that,
355 exactly as with all REMAP Modes, the `svshape` instruction *requests*
356 a certain Vector Length (number of elements to reduce) and then
357 sets VL and MAXVL at the number of **operations** needed to be
358 carried out. Thus, equally as importantly, like Matrix REMAP
359 the total number of operations
360 is restricted to 127. Any Parallel-Reduction requiring more operations
361 will need to be done manually in batches (hierarchical
362 recursive Reduction).
364 Also important to note is that the Deterministic Schedule is arranged
365 so that some implementations *may* parallelise it (as long as doing so
366 respects Program Order and Register Hazards). Performance (speed)
368 implementation is neither strictly defined or guaranteed. As with
369 the Vulkan(tm) Specification, strict compliance is paramount whilst
370 performance is at the discretion of Implementors.
372 **Parallel-Reduction with Predication**
374 To avoid breaking the strict RISC-paradigm, keeping the Issue-Schedule
375 completely separate from the actual element-level (scalar) operations,
376 Move operations are **not** included in the Schedule. This means that
377 the Schedule leaves the final (scalar) result in the first-non-masked
378 element of the Vector used. With the predicate mask being dynamic
379 (but deterministic) at a superficial glance it seems this result
382 If that result is needed to be moved to a (single) scalar register
383 then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
384 needed to get it, where the predicate is the exact same predicate used
385 in the prior Parallel-Reduction instruction.
387 * If there was only a single
388 bit in the predicate then the result will not have moved or been altered
389 from the source vector prior to the Reduction
390 * If there was more than one bit the result will be in the
391 first element with a predicate bit set.
393 In either case the result is in the element with the first bit set in
394 the predicate mask. Thus, no move/copy *within the Reduction itself* was needed.
396 Programmer's Note: For *some* hardware implementations
397 the vector-to-scalar copy may be a slow operation, as may the Predicated
398 Parallel Reduction itself.
399 It may be better to perform a pre-copy
400 of the values, compressing them (VREDUCE-style) into a contiguous block,
401 which will guarantee that the result goes into the very first element
402 of the destination vector, in which case clearly no follow-up
403 predicated vector-to-scalar MV operation is needed. A VREDUCE effect
404 is achieved by setting just a source predicate mask on Twin-Predicated
409 The simplest usage is to perform an overwrite, specifying all three
410 register operands the same.
413 svshape parallelreduce, 6
417 The Reduction Schedule will issue the Parallel Tree Reduction spanning
418 registers 8 through 13, by adjusting the offsets to RT, RA and RB as
419 necessary (see "Parallel Reduction algorithm" in a later section).
421 A non-overwrite is possible as well but just as with the overwrite
422 version, only those destination elements necessary for storing
423 intermediary computations will be written to: the remaining elements
424 will **not** be overwritten and will **not** be zero'd.
427 svshape parallelreduce, 6
431 However it is critical to note that if the source and destination are
432 not the same then the trick of using a follow-up vector-scalar MV will
435 **Sub-Vector Horizontal Reduction**
437 To achieve Sub-Vector Horizontal Reduction, Pack/Unpack should be enabled,
438 which will turn the Schedule around such that issuing of the Scalar
439 Defined Word-instructions is done with SUBVL looping as the inner loop not the
440 outer loop. Rc=1 with Sub-Vectors (SUBVL=2,3,4) is `UNDEFINED` behaviour.
442 *Programmer's Note: Overwrite Parallel Reduction with Sub-Vectors
443 will clearly result in data corruption. It may be best to perform
444 a Pack/Unpack Transposing copy of the data first*
448 submode2=0 is for FFT. For FFT submode the following schedules may be
451 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
453 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
455 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
457 When submode2 is 1 or 2, for DCT inner butterfly submode the following
458 schedules may be selected. When submode2 is 1, additional bit-reversing
461 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
463 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
464 in reverse-order, in-place
465 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
466 useful for calculating the cosine coefficient
467 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
468 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
470 When submode2 is 3 or 4, for DCT outer butterfly submode the following
471 schedules may be selected. When submode is 3, additional bit-reversing
474 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
475 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
477 `zdimsz` is used as an in-place "Stride", particularly useful for
478 column-based in-place DCT/FFT.
482 In Matrix Mode, skip allows dimensions to be skipped from being included
483 in the resultant output index. This allows sequences to be repeated:
484 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
485 modulo ```0 1 2 0 1 2 ...```
487 * **skip=0b00** indicates no dimensions to be skipped
488 * **skip=0b01** sets "skip 1st dimension"
489 * **skip=0b10** sets "skip 2nd dimension"
490 * **skip=0b11** sets "skip 3rd dimension"
492 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
493 zero then x-dimensional counting begins from 0 and increments, otherwise
494 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
496 offset will have the effect of offsetting the result by ```offset``` elements:
500 GPR(RT + remap(i) + SVSHAPE.offset) = ....
503 This appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. Also
504 bear in mind that unlike a static compiler SVSHAPE.offset may
505 be set dynamically at runtime.
507 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
508 that the array dimensionality for that dimension is 1. any dimension
509 not intended to be used must have its value set to 0 (dimensionality
510 of 1). A value of xdimsz=2 would indicate that in the first dimension
511 there are 3 elements in the array. For example, to create a 2D array
512 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
514 The format of the array is therefore as follows:
517 array[xdimsz+1][ydimsz+1][zdimsz+1]
520 However whilst illustrative of the dimensionality, that does not take the
521 "permute" setting into account. "permute" may be any one of six values
522 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
523 below shows how the permutation dimensionality order works:
525 | permute | order | array format |
526 | ------- | ----- | ------------------------ |
527 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
528 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
529 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
530 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
531 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
532 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
533 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
534 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
536 In other words, the "permute" option changes the order in which
537 nested for-loops over the array would be done. See executable
538 python reference code for further details.
540 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
543 With all these options it is possible to support in-place transpose,
544 in-place rotate, Matrix Multiply and Convolutions, without being
545 limited to Power-of-Two dimension sizes.
547 **Limitations and caveats**
549 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
550 restricted to 127: up to 127 FMAs (or other operation)
551 may be performed in total.
552 Also given that it is in-registers only at present some care has to be
553 taken on regfile resource utilisation. However it is perfectly possible
554 to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
555 the usual 6-level "Tiled" large Matrix Multiply, without the usual
556 difficulties associated with SIMD.
558 Also the `svshape` instruction only provides access to *part* of the
559 Matrix REMAP capability. Rotation and mirroring need to be done by
560 programming the SVSHAPE SPRs directly, which can take a lot more
561 instructions. Future versions of SVP64 will
562 provide more comprehensive capacity and
563 mitigate the need to write direct to the SVSHAPE SPRs.
565 Additionally there is not yet a way to set Matrix sizes from registers
566 with `svshape`: this was an intentional decision to simplify Hardware, that
567 may be corrected in a future version of SVP64. The limitation may presently
568 be overcome by direct programming of the SVSHAPE SPRs.
570 *Hardware Architectural note: with the Scheduling applying as a Phase between
571 Decode and Issue in a Deterministic fashion the Register Hazards may be
572 easily computed and a standard Out-of-Order Micro-Architecture exploited to good
573 effect. Even an In-Order system may observe that for large Outer Product
574 Schedules there will be no stalls, but if the Matrices are particularly
575 small size an In-Order system would have to stall, just as it would if
576 the operations were loop-unrolled without Simple-V. Thus: regardless
577 of the Micro-Architecture the Hardware Engineer should first consider
578 how best to process the exact same equivalent loop-unrolled instruction
579 stream. Once solved Matrix REMAP will fit naturally.*
583 Indexed Mode activates reading of the element indices from the GPR
584 and includes optional limited 2D reordering.
585 In its simplest form (without elwidth overrides or other modes):
589 return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
592 element_result = ....
593 GPR(RT + indexed_remap(i)) = element_result
596 With element-width overrides included, and using the pseudocode
597 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
602 svreg = SVSHAPE.SVGPR << 1
603 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
604 offs = SVSHAPE.offset
605 return get_polymorphed_reg(svreg, srcwid, i) + offs
608 element_result = ....
609 rt_idx = indexed_remap(i)
610 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
613 Matrix-style reordering still applies to the indices, except limited
614 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
615 (Y,X) for in-place Transposition.
616 Only one dimension may optionally be skipped. Inversion of either
617 X or Y or both is possible (2D mirroring). Pseudocode for Indexed Mode (including elwidth
618 overrides) may be written in terms of Matrix Mode, specifically
619 purposed to ensure that the 3rd dimension (Z) has no effect:
622 def index_remap(ISHAPE, i):
623 MSHAPE.skip = 0b0 || ISHAPE.sk1
624 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
625 MSHAPE.xdimsz = ISHAPE.xdimsz
626 MSHAPE.ydimsz = ISHAPE.ydimsz
627 MSHAPE.zdimsz = 0 # disabled
628 if ISHAPE.permute = 0b110 # 0,1
629 MSHAPE.permute = 0b000 # 0,1,2
630 if ISHAPE.permute = 0b111 # 1,0
631 MSHAPE.permute = 0b010 # 1,0,2
632 el_idx = remap_matrix(MSHAPE, i)
633 svreg = ISHAPE.SVGPR << 1
634 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
636 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
639 The most important observation above is that the Matrix-style
640 remapping occurs first and the Index lookup second. Thus it
641 becomes possible to perform in-place Transpose of Indices which
642 may have been costly to set up or costly to duplicate
643 (waste register file space). In other words: it is fine for two or more
644 SVSHAPEs to simultaneously use the same
645 Indices (use the same GPRs), even if one SVSHAPE has different
646 2D dimensions and ordering from the others.
648 **Caveats and Limitations**
650 The purpose of Indexing is to provide a generalised version of
651 Vector ISA "Permute" instructions, such as VSX `vperm`. The
652 Indexing is abstracted out and may be applied to much more
653 than an element move/copy, and is not limited for example
654 to the number of bytes that can fit into a VSX register.
655 Indexing may be applied to LD/ST (even on Indexed LD/ST
656 instructions such as `sv.lbzx`), arithmetic operations,
657 extsw: there is no artificial limit.
659 The only major caveat is that the registers to be used as
660 Indices must not be modified by any instruction after Indexed Mode
661 is established, and neither must MAXVL be altered. Additionally,
662 no register used as an Index may exceed MAXVL-1.
665 these conditions results in `UNDEFINED` behaviour.
666 These conditions allow a Read-After-Write (RAW) Hazard to be created on
667 the entire range of Indices to be subsequently used, but a corresponding
668 Write-After-Read Hazard by any instruction that modifies the Indices
669 **does not have to be created**. Given the large number of registers
670 involved in Indexing this is a huge resource saving and reduction
671 in micro-architectural complexity. MAXVL is likewise
672 included in the RAW Hazards because it is involved in calculating
673 how many registers are to be considered Indices.
675 With these Hazard Mitigations in place, high-performance implementations
676 may read-cache the Indices at the point where a given `svindex` instruction
677 is called (or SVSHAPE SPRs - and MAXVL - directly altered) by issuing
678 background GPR register file reads whilst other instructions are being
681 Indexed REMAP **does not prevent conflicts** (overlapping
682 destinations), which on a superficial analysis may be perceived to be a
683 problem, until it is recalled that, firstly, Simple-V is designed specifically
684 to require Program Order to be respected, and that Matrix, DCT and FFT
685 all *already* critically depend on overlapping Reads/Writes: Matrix
686 uses overlapping registers as accumulators. Thus the Register Hazard
687 Management needed by Indexed REMAP *has* to be in place anyway.
689 *Programmer's Note: `hphint` may be used to help hardware identify
690 parallelism opportunities but it is critical to remember that the
691 groupings are by `FLOOR(step/MAXVL)` not `FLOOR(REMAP(step)/MAXVL)`.*
693 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
694 clearly that of the additional reading of the GPRs to be used as Indices,
695 plus the setup cost associated with creating those same Indices.
696 If any Deterministic REMAP can cover the required task, clearly it
697 is adviseable to use it instead.
699 *Programmer's note: some algorithms may require skipping of Indices exceeding
700 VL-1, not MAXVL-1. This may be achieved programmatically by performing
701 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
702 and RB contains the value of VL returned from `setvl`. The resultant
703 CR Fields may then be used as Predicate Masks to exclude those operations
704 with an Index exceeding VL-1.*
710 # svshape instruction <a name="svshape"> </a>
714 svshape SVxd,SVyd,SVzd,SVRM,vf
716 | 0:5|6:10 |11:15 |16:20 | 21:24 | 25 | 26:31 | name |
717 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
718 |PO | SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
720 See [[sv/remap/appendix]] for `svshape` pseudocode
722 Special Registers Altered:
728 `svshape` is a convenience instruction that reduces instruction
729 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
730 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
731 including VL and MAXVL. Using `svshape` therefore does not also
736 * **SVxd** - SV REMAP "xdim" (X-dimension)
737 * **SVyd** - SV REMAP "ydim" (Y-dimension, sometimes used for sub-mode selection)
738 * **SVzd** - SV REMAP "zdim" (Z-dimension)
739 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
740 * **vf** - sets "Vertical-First" mode
741 * **XO** - standard 6-bit XO field
743 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
744 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
746 There are 12 REMAP Modes (2 Modes are RESERVED for `svshape2`, 2 Modes
749 | SVRM | Remap Mode description |
751 | 0b0000 | Matrix 1/2/3D |
752 | 0b0001 | FFT Butterfly |
753 | 0b0010 | reserved |
754 | 0b0011 | DCT Outer butterfly |
755 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
756 | 0b0101 | DCT COS table index generation |
757 | 0b0110 | DCT half-swap |
758 | 0b0111 | Parallel Reduction and Prefix Sum |
759 | 0b1000 | reserved for svshape2 |
760 | 0b1001 | reserved for svshape2 |
761 | 0b1010 | reserved |
762 | 0b1011 | iDCT Outer butterfly |
763 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
764 | 0b1101 | iDCT COS table index generation |
765 | 0b1110 | iDCT half-swap |
766 | 0b1111 | FFT half-swap |
768 Examples showing how all of these Modes operate exists in the online
769 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD). Explaining
770 these Modes further in detail is beyond the scope of this document.
772 In Indexed Mode, there are only 5 bits available to specify the GPR
773 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
774 5 bits are given in the `SVxd` field: the bottom two implicit bits
775 will be zero (`SVxd || 0b00`).
777 `svshape` has *limited applicability* due to being a 32-bit instruction.
778 The full capability of SVSHAPE SPRs may be accessed by directly writing
779 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
780 larger than 32, and in-place Transpose. Potentially a future
781 instruction may extend the capability here.
783 Programmer's Note: Parallel Reduction Mode is selected by setting `SVRM=7,SVyd=1`.
784 Prefix Sum Mode is selected by setting `SVRM=7,SVyd=3`:
787 # Vector length of 8.
788 svshape 8, 3, 1, 0x7, 0
789 # activate SVSHAPE0 (prefix-sum lhs) for RA
790 # activate SVSHAPE1 (prefix-sum rhs) for RT and RB
791 svremap 7, 0, 1, 0, 1, 0, 0
795 *Architectural Resource Allocation note: the SVRM field is carefully
796 crafted to allocate two Modes, corresponding to bits 21-23 within the
797 instruction being set to the value `0b100`, to `svshape2` (not
798 `svshape`). These two Modes are
799 considered "RESERVED" within the context of `svshape` but it is
800 absolutely critical to allocate the exact same pattern in XO for
801 both instructions in bits 26-31.*
808 # svindex instruction <a name="svindex"> </a>
812 | 0:5|6:10 |11:15 |16:20 | 21:25 | 26:31 | Form |
813 | -- | -- | --- | ---- | ----------- | ------| -------- |
814 | PO | SVG | rmm | SVd | ew/yx/mm/sk | XO | SVI-Form |
816 * svindex SVG,rmm,SVd,ew,SVyx,mm,sk
818 See [[sv/remap/appendix]] for `svindex` pseudocode
820 Special Registers Altered:
826 `svindex` is a convenience instruction that reduces instruction count
827 for Indexed REMAP Mode. It sets up (overwrites) all required SVSHAPE
828 SPRs and **unlike** `svshape` can modify the REMAP area of the SVSTATE
829 SPR as well, including setting persistence. The relevant SPRs *may*
830 be directly programmed with `mtspr` however it is laborious to do so:
831 svindex saves instructions covering much of Indexed REMAP capability.
835 * **SVd** - SV REMAP x/y dim
836 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
838 * **ew** - sets element width override on the Indices
839 * **SVG** - GPR SVG<<2 to be used for Indexing
840 * **yx** - 2D reordering to be used if yx=1
841 * **mm** - mask mode. determines how `rmm` is interpreted.
842 * **sk** - Dimension skipping enabled
844 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
845 "off-by-one". In the assembler
846 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
848 *Note: when `yx=1,sk=0` the second dimension is calculated as
853 * `rmm`, like REMAP.SVme, has bit 0
854 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
855 bit 3 to mo0 and bit 4 to mi1
856 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
857 * for each bit set in the 5-bit `rmm`, in order, the first
858 as-yet-unset SVSHAPE will be updated
859 with the other operands in the instruction, and the REMAP
861 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
862 * SVSTATE persistence bit is cleared
863 * No other alterations to SVSTATE are carried out
865 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
866 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
867 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
868 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
870 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
871 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
872 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
874 Rough algorithmic form:
877 marray = [mi0, mi1, mi2, mo0, mo1]
880 if not rmm[bit]: continue
882 SVSTATE{marray[bit]} = idx
883 idx = (idx+1) modulo 4
888 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
889 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
891 * only the selected SVSHAPE is overwritten
892 * only the relevant bits in the REMAP area of SVSTATE are updated
893 * REMAP persistence bit is set.
895 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
896 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
897 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
900 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
901 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
902 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
905 Rough algorithmic form:
908 marray = [mi0, mi1, mi2, mo0, mo1]
912 SVSTATE{marray[bit]} = idx
916 In essence, `mm=0` is intended for use to set as much of the
917 REMAP State SPRs as practical with a single instruction,
918 whilst `mm=1` is intended to be a little more refined.
922 * **Disable 2D mapping**: to only perform Indexing without
923 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
925 * **Modulo 1D mapping**: to perform Indexing cycling through the
926 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
927 no requirement to set VL equal to a multiple of N.
928 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
929 `xdim=M,ydim=CEIL(MAXVL/M)`.
931 Beyond these mappings it becomes necessary to write directly to
932 the SVSTATE SPRs manually.
939 # svshape2 (offset-priority) <a name="svshape2"> </a>
943 | 0:5|6:9 |10|11:15 |16:20 | 21:24 | 25 | 26:31 | Form |
944 | -- |----|--| --- | ----- | ------ | -- | ------| -------- |
945 | PO |offs|yx| rmm | SVd | 100/mm | sk | XO | SVM2-Form |
947 * svshape2 offs,yx,rmm,SVd,sk,mm
949 See [[sv/remap/appendix]] for `svshape2` pseudocode
951 Special Registers Altered:
957 `svshape2` is an additional convenience instruction that prioritises
958 setting `SVSHAPE.offset`. Its primary purpose is for use when
959 element-width overrides are used. It has identical capabilities to `svindex`
960 in terms of both options (skip, etc.) and ability to activate REMAP
961 (rmm, mask mode) but unlike `svindex` it does not set GPR REMAP:
962 only a 1D or 2D `svshape`, and
963 unlike `svshape` it can set an arbitrary `SVSHAPE.offset` immediate.
965 One of the limitations of Simple-V is that Vector elements start on the boundary
966 of the Scalar regfile, which is fine when element-width overrides are not
967 needed. If the starting point of a Vector with smaller elwidths must begin
968 in the middle of a register, normally there would be no way to do so except
969 through costly LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`
970 makes it easier to access.
974 * **offs** (4 bits) - unsigned offset
975 * **yx** (1 bit) - swap XY to YX
976 * **SVd** dimension size
979 * **sk** (1 bit) skips 1st dimension if set
981 Dimensions are calculated exactly as `svindex`. `rmm` and
982 `mm` are as per `svindex`.
984 *Programmer's Note: offsets for `svshape2` may be specified in the range
985 0-15. Given that the principle of Simple-V is to fit on top of
986 byte-addressable register files and that GPR and FPR are 64-bit (8 bytes)
987 it should be clear that the offset may, when `elwidth=8`, begin an
988 element-level operation starting element zero at any arbitrary byte.
989 On cursory examination attempting to go beyond the range 0-7 seems
990 unnecessary given that the **next GPR or FPR** is an
991 alias for an offset in the range 8-15. Thus by simply increasing
992 the starting Vector point of the operation to the next register it
993 can be seen that the offset of 0-7 would be sufficient. Unfortunately
994 however some operations are EXTRA2-encoded it is **not possible**
995 to increase the GPR/FPR register number by one, because EXTRA2-encoding
996 of GPR/FPR Vector numbers are restricted to even numbering.
997 For CR Fields the EXTRA2 encoding is even more sparse.
998 The additional offset range (8-15) helps overcome these limitations.*
1000 *Hardware Implementor's note: with the offsets only being immediates
1001 and with register numbering being entirely immediate as well it is
1002 possible to correctly compute Register Hazards without requiring
1003 reading the contents of any SPRs. If however there are
1004 instructions that have directly written to the SVSTATE or SVSHAPE
1005 SPRs and those instructions are still in-flight then this position
1006 is clearly **invalid**. This is why Programmers are strongly
1007 discouraged from directly writing to these SPRs.*
1009 *Architectural Resource Allocation note: this instruction shares
1010 the space of `svshape`. Therefore it is critical that the two
1011 instructions, `svshape` and `svshape2` have the exact same XO
1012 in bits 26 thru 31. It is also critical that for `svshape2`,
1013 bit 21 of XO is a 1, bit 22 of XO is a 0, and bit 23 of XO is a 0.*