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 * see [[sv/remap/appendix]] for examples and usage
11 * see [[sv/propagation]] for a future way to apply REMAP
12 * [[remap/discussion]]
15 REMAP is an advanced form of Vector "Structure Packing" that provides
16 hardware-level support for commonly-used *nested* loop patterns that would
17 otherwise require full inline loop unrolling. For more general reordering
18 an Indexed REMAP mode is available (an abstracted analog to `xxperm`).
20 REMAP allows the usual sequential vector loop `0..VL-1` to be "reshaped"
21 (re-mapped) from a linear form to a 2D or 3D transposed form, or "offset"
22 to permit arbitrary access to elements (when elwidth overrides are
23 used), independently on each Vector src or dest register. Aside from
24 Indexed REMAP this is entirely Hardware-accelerated reordering and
25 consequently not costly in terms of register access. It will however
26 place a burden on Multi-Issue systems but no more than if the equivalent
27 Scalar instructions were explicitly loop-unrolled without SVP64, and
28 some advanced implementations may even find the Deterministic nature of
29 the Scheduling to be easier on resources.
31 The initial primary motivation of REMAP was for Matrix Multiplication,
32 reordering of sequential data in-place: in-place DCT and FFT were
33 easily justified given the exceptionally high usage in Computer Science.
34 Four SPRs are provided which may be applied to any GPR, FPR or CR Field so
35 that for example a single FMAC may be used in a single hardware-controlled
36 100% Deterministic loop to perform 5x3 times 3x4 Matrix multiplication,
37 generating 60 FMACs *without needing explicit assembler unrolling*.
38 Additional uses include regular "Structure Packing" such as RGB pixel
39 data extraction and reforming (although less costly vec2/3/4 reshaping
40 is achievable with `PACK/UNPACK`).
42 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
43 Vector ISAs which would typically only have a limited set of instructions
44 that can be structure-packed (LD/ST and Move operations
45 being the most common), REMAP may be applied to
46 literally any instruction: CRs, Arithmetic, Logical, LD/ST, even
47 Vectorised Branch-Conditional.
49 When SUBVL is greater than 1 a given group of Subvector
50 elements are kept together: effectively the group becomes the
51 element, and with REMAP applying to elements
52 (not sub-elements) each group is REMAPed together.
53 Swizzle *can* however be applied to the same
54 instruction as REMAP, providing re-sequencing of
55 Subvector elements which REMAP cannot. Also as explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack Mode bits
56 can extend down into Sub-vector elements to influence vec2/vec3/vec4
57 sequential reordering, but even here, REMAP reordering is not *individually*
58 extended down to the actual sub-vector elements themselves.
59 This keeps the relevant Predicate Mask bit applicable to the Subvector
60 group, just as it does when REMAP is not active.
62 In its general form, REMAP is quite expensive to set up, and on some
63 implementations may introduce latency, so should realistically be used
64 only where it is worthwhile. Given that even with latency the fact
65 that up to 127 operations can be Deterministically issued (from a single
66 instruction) it should be clear that REMAP should not be dismissed
67 for *possible* latency alone. Commonly-used patterns such as Matrix
68 Multiply, DCT and FFT have helper instruction options which make REMAP
71 There are four types of REMAP:
73 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
74 Matrix transpose and rotate. The Shapes are set up for an "Outer Product"
76 * **FFT/DCT**, with full triple-loop in-place support: limited to
78 * **Indexing**, for any general-purpose reordering, also includes
79 limited 2D reshaping as well as Element "offsetting".
80 * **Parallel Reduction**, for scheduling a sequence of operations
81 in a Deterministic fashion, in a way that may be parallelised,
82 to reduce a Vector down to a single value.
84 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
85 REMAP Schedules are 100% Deterministic **including Indexing** and are
86 designed to be incorporated in between the Decode and Issue phases,
87 directly into Register Hazard Management.
89 As long as the SVSHAPE SPRs
90 are not written to directly, Hardware may treat REMAP as 100%
91 Deterministic: all REMAP Management instructions take static
92 operands (no dynamic register operands)
93 with the exception of Indexed Mode, and even then
94 Architectural State is permitted to assume that the Indices
95 are cacheable from the point at which the `svindex` instruction
98 Parallel Reduction is unusual in that it requires a full vector array
99 of results (not a scalar) and uses the rest of the result Vector for
100 the purposes of storing intermediary calculations. As these intermediary
101 results are Deterministically computed they may be useful.
102 Additionally, because the intermediate results are always written out
103 it is possible to service Precise Interrupts without affecting latency
104 (a common limitation of Vector ISAs implementing explicit
105 Parallel Reduction instructions, because their Architectural State cannot
106 hold the partial results).
110 * normal vector element read/write of operands would be sequential
112 * this is not appropriate for (e.g.) Matrix multiply which requires
113 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
114 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
115 with this. both are expensive (copy large vectors, spill through memory)
116 and very few Packed SIMD ISAs cope with non-Power-2.
117 * REMAP **redefines** the order of access according to set
118 (Deterministic) "Schedules".
119 * Matrix Schedules are not at all restricted to power-of-two boundaries
120 making it unnecessary to have for example specialised 3x4 transpose
121 instructions of other Vector ISAs.
123 Only the most commonly-used algorithms in computer science have REMAP
124 support, due to the high cost in both the ISA and in hardware. For
125 arbitrary remapping the `Indexed` REMAP may be used.
129 * `svshape` to set the type of reordering to be applied to an
130 otherwise usual `0..VL-1` hardware for-loop
131 * `svremap` to set which registers a given reordering is to apply to
133 * `sv.{instruction}` where any Vectorised register marked by `svremap`
134 will have its ordering REMAPPED according to the schedule set
137 The following illustrative example multiplies a 3x4 and a 5x3
142 svshape 5, 4, 3, 0, 0 # Outer Product
143 svremap 15, 1, 2, 3, 0, 0, 0, 0
144 sv.fmadds *0, *32, *64, *0
147 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
148 * svremap activates four out of five registers RA RB RC RT RS (15)
154 - RS Remapping to not be activated
155 * sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
156 * With REMAP being active each register's element index is
157 *independently* transformed using the specified SHAPEs.
159 Thus the Vector Loop is arranged such that the use of
160 the multiply-and-accumulate instruction executes precisely the required
161 Schedule to perform an in-place in-registers Outer Product
162 Matrix Multiply with no
163 need to perform additional Transpose or register copy instructions.
164 The example above may be executed as a unit test and demo,
165 [here](https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_matrix.py;h=c15479db9a36055166b6b023c7495f9ca3637333;hb=a17a252e474d5d5bf34026c25a19682e3f2015c3#l94)
169 This section summarises the motivation for each REMAP Schedule
170 and briefly goes over their characteristics and limitations.
171 Further details on the Deterministic Precise-Interruptible algorithms
172 used in these Schedules is found in the [[sv/remap/appendix]].
174 ### Matrix (1D/2D/3D shaping)
176 Matrix Multiplication is a huge part of High-Performance Compute,
178 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
179 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
180 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
181 Aside from the cost of the load on the L1 I-Cache, the trick only
182 works if one of the dimensions X or Y are power-two. Prime Numbers
183 (5x7, 3x5) become deeply problematic to unroll.
185 Even traditional Scalable Vector ISAs have issues with Matrices, often
186 having to perform data Transpose by pushing out through Memory and back,
187 or computing Transposition Indices (costly) then copying to another
190 Matrix REMAP was thus designed to solve these issues by providing Hardware
192 "Schedules" that can view what would otherwise be limited to a strictly
193 linear Vector as instead being 2D (even 3D) *in-place* reordered.
194 With both Transposition and non-power-two being supported the issues
195 faced by other ISAs are mitigated.
197 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
198 restricted to 127: up to 127 FMAs (or other operation)
199 may be performed in total.
200 Also given that it is in-registers only at present some care has to be
201 taken on regfile resource utilisation. However it is perfectly possible
202 to utilise Matrix REMAP to perform the three inner-most "kernel"
204 the usual 6-level large Matrix Multiply, without the usual difficulties
205 associated with SIMD.
207 Also the `svshape` instruction only provides access to part of the
208 Matrix REMAP capability. Rotation and mirroring need to be done by
209 programming the SVSHAPE SPRs directly, which can take a lot more
210 instructions. Future versions of SVP64 will include EXT1xx prefixed
211 variants (`psvshape`) which provide more comprehensive capacity and
212 mitigate the need to write direct to the SVSHAPE SPRs.
214 ### FFT/DCT Triple Loop
216 DCT and FFT are some of the most astonishingly used algorithms in
217 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
218 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
221 An in-depth analysis showed that it is possible to do in-place in-register
222 DCT and FFT as long as twin-result "butterfly" instructions are provided.
223 These can be found in the [[openpower/isa/svfparith]] page if performing
224 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
225 integer operations would be required)*. These "butterfly" instructions
226 avoid the need for a temporary register because the two array positions
227 being overwritten will be "in-flight" in any In-Order or Out-of-Order
230 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
231 accept predicate masks. Given that it is common to perform recursive
232 convolutions combining smaller Power-2 DCT/FFT to create larger DCT/FFTs
233 in practice the RADIX2 limit is not a problem. A Bluestein convolution
234 to compute arbitrary length is demonstrated by
235 [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
239 The purpose of Indexing is to provide a generalised version of
240 Vector ISA "Permute" instructions, such as VSX `vperm`. The
241 Indexing is abstracted out and may be applied to much more
242 than an element move/copy, and is not limited for example
243 to the number of bytes that can fit into a VSX register.
244 Indexing may be applied to LD/ST (even on Indexed LD/ST
245 instructions such as `sv.lbzx`), arithmetic operations,
246 extsw: there is no artificial limit.
248 The only major caveat is that the registers to be used as
249 Indices must not be modified by any instruction after Indexed Mode
250 is established, and neither must MAXVL be altered. Additionally,
251 no register used as an Index may exceed MAXVL-1.
254 these conditions results in `UNDEFINED` behaviour.
255 These conditions allow a Read-After-Write (RAW) Hazard to be created on
256 the entire range of Indices to be subsequently used, but a corresponding
257 Write-After-Read Hazard by any instruction that modifies the Indices
258 **does not have to be created**. Given the large number of registers
259 involved in Indexing this is a huge resource saving and reduction
260 in micro-architectural complexity. MAXVL is likewise
261 included in the RAW Hazards because it is involved in calculating
262 how many registers are to be considered Indices.
264 With these Hazard Mitigations in place, high-performance implementations
265 may read-cache the Indices at the point where a given `svindex` instruction
266 is called (or SVSHAPE SPRs - and MAXVL - directly altered) by issuing
267 background GPR register file reads whilst other instructions are being
270 The original motivation for Indexed REMAP was to mitigate the need to add
271 an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
272 a stand-alone instruction. Usually a Vector ISA would add a non-conflicting
273 variant (as in VSX `vperm`) but it is common to need to permute by source,
274 with the risk of conflict, that has to be resolved, for example, in AVX-512
277 Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
278 destinations), which on a superficial analysis may be perceived to be a
279 problem, until it is recalled that, firstly, Simple-V is designed specifically
280 to require Program Order to be respected, and that Matrix, DCT and FFT
281 all *already* critically depend on overlapping Reads/Writes: Matrix
282 uses overlapping registers as accumulators. Thus the Register Hazard
283 Management needed by Indexed REMAP *has* to be in place anyway.
285 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
286 clearly that of the additional reading of the GPRs to be used as Indices,
287 plus the setup cost associated with creating those same Indices.
288 If any Deterministic REMAP can cover the required task, clearly it
289 is adviseable to use it instead.
291 *Programmer's note: some algorithms may require skipping of Indices exceeding
292 VL-1, not MAXVL-1. This may be achieved programmatically by performing
293 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
294 and RB contains the value of VL returned from `setvl`. The resultant
295 CR Fields may then be used as Predicate Masks to exclude those operations
296 with an Index exceeding VL-1.*
298 ### Parallel Reduction
300 Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
301 (Power ISA v3.0B) operation is leveraged, unmodified, to give the
302 *appearance* and *effect* of Reduction.
304 In Horizontal-First Mode, Vector-result reduction **requires**
305 the destination to be a Vector, which will be used to store
306 intermediary results.
308 Given that the tree-reduction schedule is deterministic,
309 Interrupts and exceptions
310 can therefore also be precise. The final result will be in the first
311 non-predicate-masked-out destination element, but due again to
312 the deterministic schedule programmers may find uses for the intermediate
315 When Rc=1 a corresponding Vector of co-resultant CRs is also
316 created. No special action is taken: the result *and its CR Field*
317 are stored "as usual" exactly as all other SVP64 Rc=1 operations.
319 Note that the Schedule only makes sense on top of certain instructions:
320 X-Form with a Register Profile of `RT,RA,RB` is fine because two sources
321 and the destination are all the same type. Like Scalar
322 Reduction, nothing is prohibited:
323 the results of execution on an unsuitable instruction may simply
324 not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
325 may be used, and whilst it is down to the Programmer to walk through the
326 process the Programmer can be confident that the Parallel-Reduction is
327 guaranteed 100% Deterministic.
329 Critical to note regarding use of Parallel-Reduction REMAP is that,
330 exactly as with all REMAP Modes, the `svshape` instruction *requests*
331 a certain Vector Length (number of elements to reduce) and then
332 sets VL and MAXVL at the number of **operations** needed to be
333 carried out. Thus, equally as importantly, like Matrix REMAP
334 the total number of operations
335 is restricted to 127. Any Parallel-Reduction requiring more operations
336 will need to be done manually in batches (hierarchical
337 recursive Reduction).
339 Also important to note is that the Deterministic Schedule is arranged
340 so that some implementations *may* parallelise it (as long as doing so
341 respects Program Order and Register Hazards). Performance (speed)
343 implementation is neither strictly defined or guaranteed. As with
344 the Vulkan(tm) Specification, strict compliance is paramount whilst
345 performance is at the discretion of Implementors.
347 **Parallel-Reduction with Predication**
349 To avoid breaking the strict RISC-paradigm, keeping the Issue-Schedule
350 completely separate from the actual element-level (scalar) operations,
351 Move operations are **not** included in the Schedule. This means that
352 the Schedule leaves the final (scalar) result in the first-non-masked
353 element of the Vector used. With the predicate mask being dynamic
354 (but deterministic) this result could be anywhere.
356 If that result is needed to be moved to a (single) scalar register
357 then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
358 needed to get it, where the predicate is the exact same predicate used
359 in the prior Parallel-Reduction instruction.
361 * If there was only a single
362 bit in the predicate then the result will not have moved or been altered
363 from the source vector prior to the Reduction
364 * If there was more than one bit the result will be in the
365 first element with a predicate bit set.
367 In either case the result is in the element with the first bit set in
368 the predicate mask. Thus, no move/copy *within the Reduction itself* was needed.
370 Programmer's Note: For *some* hardware implementations
371 the vector-to-scalar copy may be a slow operation, as may the Predicated
372 Parallel Reduction itself.
373 It may be better to perform a pre-copy
374 of the values, compressing them (VREDUCE-style) into a contiguous block,
375 which will guarantee that the result goes into the very first element
376 of the destination vector, in which case clearly no follow-up
377 predicated vector-to-scalar MV operation is needed.
381 The simplest usage is to perform an overwrite, specifying all three
382 register operands the same.
385 svshape parallelreduce, 6
389 The Reduction Schedule will issue the Parallel Tree Reduction spanning
390 registers 8 through 13, by adjusting the offsets to RT, RA and RB as
391 necessary (see "Parallel Reduction algorithm" in a later section).
393 A non-overwrite is possible as well but just as with the overwrite
394 version, only those destination elements necessary for storing
395 intermediary computations will be written to: the remaining elements
396 will **not** be overwritten and will **not** be zero'd.
399 svshape parallelreduce, 6
403 However it is critical to note that if the source and destination are
404 not the same then the trick of using a follow-up vector-scalar MV will
407 ### Sub-Vector Horizontal Reduction
409 To achieve Sub-Vector Horizontal Reduction, Pack/Unpack should be enabled,
410 which will turn the Schedule around such that issuing of the Scalar
411 Defined Words is done with SUBVL looping as the inner loop not the
412 outer loop. Rc=1 with Sub-Vectors (SUBVL=2,3,4) is `UNDEFINED` behaviour.
414 ## Determining Register Hazards
416 For high-performance (Multi-Issue, Out-of-Order) systems it is critical
417 to be able to statically determine the extent of Vectors in order to
418 allocate pre-emptive Hazard protection. The next task is to eliminate
419 masked-out elements using predicate bits, freeing up the associated
422 For non-REMAP situations `VL` is sufficient to ascertain early
423 Hazard coverage, and with SVSTATE being a high priority cached
424 quantity at the same level of MSR and PC this is not a problem.
426 The problems come when REMAP is enabled. Indexed REMAP must instead
427 use `MAXVL` as the earliest (simplest)
428 batch-level Hazard Reservation indicator (after taking element-width
429 overriding on the Index source into consideration),
430 but Matrix, FFT and Parallel Reduction must all use completely different
431 schemes. The reason is that VL is used to step through the total
432 number of *operations*, not the number of registers.
433 The "Saving Grace" is that all of the REMAP Schedules are 100% Deterministic.
435 Advance-notice Parallel computation and subsequent cacheing
436 of all of these complex Deterministic REMAP Schedules is
437 *strongly recommended*, thus allowing clear and precise multi-issue
438 batched Hazard coverage to be deployed, *even for Indexed Mode*.
439 This is only possible for Indexed due to the strict guidelines
440 given to Programmers.
442 In short, there exists solutions to the problem of Hazard Management,
443 with varying degrees of refinement possible at correspondingly
444 increasing levels of complexity in hardware.
446 A reminder: when Rc=1 each result register (element) has an associated
447 co-result CR Field (one per result element). Thus above when determining
448 the Write-Hazards for result registers the corresponding Write-Hazards for the
449 corresponding associated co-result CR Field must not be forgotten, *including* when
452 ## REMAP area of SVSTATE SPR
454 The following bits of the SVSTATE SPR are used for REMAP:
456 |32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
457 | -- | -- | -- | -- | -- | ----- | ------ |
458 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
460 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
461 mi0-2 apply to RA, RB, RC respectively, as input registers, and
462 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
463 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
464 SVSHAPE is actively applied or not.
466 * bit 0 of SVme indicates if mi0 is applied to RA / FRA / BA / BFA
467 * bit 1 of SVme indicates if mi1 is applied to RB / FRB / BB
468 * bit 2 of SVme indicates if mi2 is applied to RC / FRC / BC
469 * bit 3 of SVme indicates if mo0 is applied to RT / FRT / BT / BF
470 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
471 (LD/ST-with-update has an implicit 2nd write register, RA)
473 The "persistence" bit if set will result in all Active REMAPs being applied
480 # svremap instruction <a name="svremap"> </a>
484 svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
486 |0 |6 |11 |13 |15 |17 |19 |21 | 22:25 |26:31 |
487 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
488 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
492 * svremap SVme,mi0,mi1,mi2,mo0,mo1,pst
497 # registers RA RB RC RT EA/FRS SVSHAPE0-3 indices
498 SVSTATE[32:33] <- mi0
499 SVSTATE[34:35] <- mi1
500 SVSTATE[36:37] <- mi2
501 SVSTATE[38:39] <- mo0
502 SVSTATE[40:41] <- mo1
503 # enable bit for RA RB RC RT EA/FRS
504 SVSTATE[42:46] <- SVme
505 # persistence bit (applies to more than one instruction)
509 Special Registers Altered:
515 `svremap` determines the relationship between registers and SVSHAPE SPRs.
516 The bitmask `SVme` determines which registers have a REMAP applied, and mi0-mo1
517 determine which shape is applied to an activated register. the `pst` bit if
518 cleared indicated that the REMAP operation shall only apply to the immediately-following
519 instruction. If set then REMAP remains permanently enabled until such time as it is
520 explicitly disabled, either by `setvl` setting a new MAXVL, or with another
521 `svremap` instruction. `svindex` and `svshape2` are also capable of setting or
522 clearing persistence, as well as partially covering a subset of the capability of
523 `svremap` to set register-to-SVSHAPE relationships.
525 Programmer's Note: applying non-persistent `svremap` to an instruction that has
526 no REMAP enabled or is a Scalar operation will obviously have no effect but
527 the bits 32 to 46 will at least have been set in SVSTATE. This may prove useful
528 when using `svindex` or `svshape2`.
530 Hardware Architectural Note: when persistence is not set it is critically important
531 to treat the `svremap` and the following SVP64 instruction as an indivisible fused operation.
532 *No state* is stored in the SVSTATE SPR in order to allow continuation should an
533 Interrupt occur between the two instructions. Thus, Interrupts must be prohibited
534 from occurring or other workaround deployed. When persistence is set this issue
537 It is critical to note that if persistence is clear then `svremap` is the *only* way
538 to activate REMAP on any given (following) instruction. If persistence is set however then
539 **all** SVP64 instructions go through REMAP as long as `SVme` is non-zero.
545 # SHAPE Remapping SPRs
547 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
548 which have the same format.
550 Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
551 disabled: the register's elements are a linear (1D) vector.
553 |31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
554 |---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
555 |mode |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
556 |0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
557 |0b01 |submode|offset| invxyz | submode2| zdimsz |mode |xdimsz|DCT/FFT|
558 |0b10 |submode|offset| invxyz | rsvd | rsvd |rsvd |xdimsz|Preduce|
559 |0b11 | | | | | | | |rsvd |
561 mode sets different behaviours (straight matrix multiply, FFT, DCT).
563 * **mode=0b00** sets straight Matrix Mode
564 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
565 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
566 * **mode=0b10** sets "Parallel Reduction" Schedules.
568 ## Parallel Reduction Mode
570 Creates the Schedules for Parallel Tree Reduction.
572 * **submode=0b00** selects the left operand index
573 * **submode=0b01** selects the right operand index
575 * When bit 0 of `invxyz` is set, the order of the indices
576 in the inner for-loop are reversed. This has the side-effect
577 of placing the final reduced result in the last-predicated element.
578 It also has the indirect side-effect of swapping the source
579 registers: Left-operand index numbers will always exceed
580 Right-operand indices.
581 When clear, the reduced result will be in the first-predicated
582 element, and Left-operand indices will always be *less* than
584 * When bit 1 of `invxyz` is set, the order of the outer loop
585 step is inverted: stepping begins at the nearest power-of two
586 to half of the vector length and reduces by half each time.
587 When clear the step will begin at 2 and double on each
592 submode2=0 is for FFT. For FFT submode the following schedules may be
595 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
597 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
599 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
601 When submode2 is 1 or 2, for DCT inner butterfly submode the following
602 schedules may be selected. When submode2 is 1, additional bit-reversing
605 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
607 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
608 in reverse-order, in-place
609 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
610 useful for calculating the cosine coefficient
611 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
612 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
614 When submode2 is 3 or 4, for DCT outer butterfly submode the following
615 schedules may be selected. When submode is 3, additional bit-reversing
618 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
619 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
621 `zdimsz` is used as an in-place "Stride", particularly useful for
622 column-based in-place DCT/FFT.
626 In Matrix Mode, skip allows dimensions to be skipped from being included
627 in the resultant output index. this allows sequences to be repeated:
628 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
629 modulo ```0 1 2 0 1 2 ...```
631 * **skip=0b00** indicates no dimensions to be skipped
632 * **skip=0b01** sets "skip 1st dimension"
633 * **skip=0b10** sets "skip 2nd dimension"
634 * **skip=0b11** sets "skip 3rd dimension"
636 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
637 zero then x-dimensional counting begins from 0 and increments, otherwise
638 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
640 offset will have the effect of offsetting the result by ```offset``` elements:
644 GPR(RT + remap(i) + SVSHAPE.offset) = ....
647 this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
648 bear in mind that unlike a static compiler SVSHAPE.offset may
649 be set dynamically at runtime.
651 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
652 that the array dimensionality for that dimension is 1. any dimension
653 not intended to be used must have its value set to 0 (dimensionality
654 of 1). A value of xdimsz=2 would indicate that in the first dimension
655 there are 3 elements in the array. For example, to create a 2D array
656 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
658 The format of the array is therefore as follows:
661 array[xdimsz+1][ydimsz+1][zdimsz+1]
664 However whilst illustrative of the dimensionality, that does not take the
665 "permute" setting into account. "permute" may be any one of six values
666 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
667 below shows how the permutation dimensionality order works:
669 | permute | order | array format |
670 | ------- | ----- | ------------------------ |
671 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
672 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
673 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
674 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
675 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
676 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
677 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
678 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
680 In other words, the "permute" option changes the order in which
681 nested for-loops over the array would be done. See executable
682 python reference code for further details.
684 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
687 With all these options it is possible to support in-place transpose,
688 in-place rotate, Matrix Multiply and Convolutions, without being
689 limited to Power-of-Two dimension sizes.
693 Indexed Mode activates reading of the element indices from the GPR
694 and includes optional limited 2D reordering.
695 In its simplest form (without elwidth overrides or other modes):
699 return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
702 element_result = ....
703 GPR(RT + indexed_remap(i)) = element_result
706 With element-width overrides included, and using the pseudocode
707 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
712 svreg = SVSHAPE.SVGPR << 1
713 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
714 offs = SVSHAPE.offset
715 return get_polymorphed_reg(svreg, srcwid, i) + offs
718 element_result = ....
719 rt_idx = indexed_remap(i)
720 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
723 Matrix-style reordering still applies to the indices, except limited
724 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
725 (Y,X) for in-place Transposition.
726 Only one dimension may optionally be skipped. Inversion of either
727 X or Y or both is possible (2D mirroring). Pseudocode for Indexed Mode (including elwidth
728 overrides) may be written in terms of Matrix Mode, specifically
729 purposed to ensure that the 3rd dimension (Z) has no effect:
732 def index_remap(ISHAPE, i):
733 MSHAPE.skip = 0b0 || ISHAPE.sk1
734 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
735 MSHAPE.xdimsz = ISHAPE.xdimsz
736 MSHAPE.ydimsz = ISHAPE.ydimsz
737 MSHAPE.zdimsz = 0 # disabled
738 if ISHAPE.permute = 0b110 # 0,1
739 MSHAPE.permute = 0b000 # 0,1,2
740 if ISHAPE.permute = 0b111 # 1,0
741 MSHAPE.permute = 0b010 # 1,0,2
742 el_idx = remap_matrix(MSHAPE, i)
743 svreg = ISHAPE.SVGPR << 1
744 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
746 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
749 The most important observation above is that the Matrix-style
750 remapping occurs first and the Index lookup second. Thus it
751 becomes possible to perform in-place Transpose of Indices which
752 may have been costly to set up or costly to duplicate
753 (waste register file space).
759 # svshape instruction <a name="svshape"> </a>
763 svshape SVxd,SVyd,SVzd,SVRM,vf
765 | 0:5|6:10 |11:15 |16:20 | 21:24 | 25 | 26:31 | name |
766 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
767 |PO | SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
770 # for convenience, VL to be calculated and stored in SVSTATE
772 mscale[0:5] <- 0b000001 # for scaling MAXVL
773 itercount[0:6] <- [0] * 7
774 SVSTATE[0:31] <- [0] * 32
775 # only overwrite REMAP if "persistence" is zero
776 if (SVSTATE[62] = 0b0) then
777 SVSTATE[32:33] <- 0b00
778 SVSTATE[34:35] <- 0b00
779 SVSTATE[36:37] <- 0b00
780 SVSTATE[38:39] <- 0b00
781 SVSTATE[40:41] <- 0b00
782 SVSTATE[42:46] <- 0b00000
785 # clear out all SVSHAPEs
786 SVSHAPE0[0:31] <- [0] * 32
787 SVSHAPE1[0:31] <- [0] * 32
788 SVSHAPE2[0:31] <- [0] * 32
789 SVSHAPE3[0:31] <- [0] * 32
791 # set schedule up for multiply
792 if (SVrm = 0b0000) then
793 # VL in Matrix Multiply is xd*yd*zd
794 xd <- (0b00 || SVxd) + 1
795 yd <- (0b00 || SVyd) + 1
796 zd <- (0b00 || SVzd) + 1
798 vlen[0:6] <- n[14:20]
799 # set up template in SVSHAPE0, then copy to 1-3
800 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
801 SVSHAPE0[6:11] <- (0b0 || SVyd) # ydim
802 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim
803 SVSHAPE0[28:29] <- 0b11 # skip z
805 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
806 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
807 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
809 SVSHAPE1[18:20] <- 0b001 # permute x,z,y
810 SVSHAPE1[28:29] <- 0b01 # skip z
812 SVSHAPE2[18:20] <- 0b001 # permute x,z,y
813 SVSHAPE2[28:29] <- 0b11 # skip y
815 # set schedule up for FFT butterfly
816 if (SVrm = 0b0001) then
817 # calculate O(N log2 N)
820 if SVxd[4-n] = 0 then
823 n <- ((0b0 || SVxd) + 1) * n
825 # set up template in SVSHAPE0, then copy to 1-3
827 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
828 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D FFT)
829 mscale <- (0b0 || SVzd) + 1
830 SVSHAPE0[30:31] <- 0b01 # Butterfly mode
832 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
833 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
835 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
837 SVSHAPE2[28:29] <- 0b10 # k schedule
839 # set schedule up for (i)DCT Inner butterfly
840 # SVrm Mode 4 (Mode 12 for iDCT) is for on-the-fly (Vertical-First Mode)
841 if ((SVrm = 0b0100) |
842 (SVrm = 0b1100)) then
843 # calculate O(N log2 N)
846 if SVxd[4-n] = 0 then
849 n <- ((0b0 || SVxd) + 1) * n
851 # set up template in SVSHAPE0, then copy to 1-3
853 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
854 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
855 mscale <- (0b0 || SVzd) + 1
856 if (SVrm = 0b1100) then
857 SVSHAPE0[30:31] <- 0b11 # iDCT mode
858 SVSHAPE0[18:20] <- 0b011 # iDCT Inner Butterfly sub-mode
860 SVSHAPE0[30:31] <- 0b01 # DCT mode
861 SVSHAPE0[18:20] <- 0b001 # DCT Inner Butterfly sub-mode
862 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop
863 SVSHAPE0[6:11] <- 0b000011 # (i)DCT Inner Butterfly mode 4
865 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
866 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
867 if (SVrm != 0b0100) & (SVrm != 0b1100) then
868 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
870 SVSHAPE0[28:29] <- 0b01 # j+halfstep schedule
871 # for cos coefficient
872 SVSHAPE2[28:29] <- 0b10 # ci (k for mode 4) schedule
873 SVSHAPE2[12:17] <- 0b000000 # reset costable "striding" to 1
874 if (SVrm != 0b0100) & (SVrm != 0b1100) then
875 SVSHAPE3[28:29] <- 0b11 # size schedule
877 # set schedule up for (i)DCT Outer butterfly
878 if (SVrm = 0b0011) | (SVrm = 0b1011) then
879 # calculate O(N log2 N) number of outer butterfly overlapping adds
883 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
884 itercount[0:6] <- (0b0 || itercount[0:5])
886 if SVxd[4-n] = 0 then
889 count <- (itercount - 0b0000001) * size
890 vlen[0:6] <- vlen + count[7:13]
891 size[0:6] <- (size[1:6] || 0b0)
892 itercount[0:6] <- (0b0 || itercount[0:5])
893 # set up template in SVSHAPE0, then copy to 1-3
895 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
896 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
897 mscale <- (0b0 || SVzd) + 1
898 if (SVrm = 0b1011) then
899 SVSHAPE0[30:31] <- 0b11 # iDCT mode
900 SVSHAPE0[18:20] <- 0b011 # iDCT Outer Butterfly sub-mode
901 SVSHAPE0[21:23] <- 0b101 # "inverse" on outer and inner loop
903 SVSHAPE0[30:31] <- 0b01 # DCT mode
904 SVSHAPE0[18:20] <- 0b100 # DCT Outer Butterfly sub-mode
905 SVSHAPE0[6:11] <- 0b000010 # DCT Butterfly mode
907 SVSHAPE1[0:31] <- SVSHAPE0[0:31] # j+halfstep schedule
908 SVSHAPE2[0:31] <- SVSHAPE0[0:31] # costable coefficients
910 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
911 # reset costable "striding" to 1
912 SVSHAPE2[12:17] <- 0b000000
914 # set schedule up for DCT COS table generation
915 if (SVrm = 0b0101) | (SVrm = 0b1101) then
916 # calculate O(N log2 N)
918 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
919 itercount[0:6] <- (0b0 || itercount[0:5])
922 if SVxd[4-n] = 0 then
925 vlen[0:6] <- vlen + itercount
926 itercount[0:6] <- (0b0 || itercount[0:5])
927 # set up template in SVSHAPE0, then copy to 1-3
929 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
930 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
931 mscale <- (0b0 || SVzd) + 1
932 SVSHAPE0[30:31] <- 0b01 # DCT/FFT mode
933 SVSHAPE0[6:11] <- 0b000100 # DCT Inner Butterfly COS-gen mode
934 if (SVrm = 0b0101) then
935 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop for DCT
937 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
938 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
939 # for cos coefficient
940 SVSHAPE1[28:29] <- 0b10 # ci schedule
941 SVSHAPE2[28:29] <- 0b11 # size schedule
943 # set schedule up for iDCT / DCT inverse of half-swapped ordering
944 if (SVrm = 0b0110) | (SVrm = 0b1110) | (SVrm = 0b1111) then
945 vlen[0:6] <- (0b00 || SVxd) + 0b0000001
946 # set up template in SVSHAPE0
947 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
948 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
949 mscale <- (0b0 || SVzd) + 1
950 if (SVrm = 0b1110) then
951 SVSHAPE0[18:20] <- 0b001 # DCT opposite half-swap
952 if (SVrm = 0b1111) then
953 SVSHAPE0[30:31] <- 0b01 # FFT mode
955 SVSHAPE0[30:31] <- 0b11 # DCT mode
956 SVSHAPE0[6:11] <- 0b000101 # DCT "half-swap" mode
958 # set schedule up for parallel reduction
959 if (SVrm = 0b0111) then
960 # calculate the total number of operations (brute-force)
962 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
963 step[0:6] <- 0b0000001
965 do while step <u itercount
966 newstep <- step[1:6] || 0b0
968 do while (j+step <u itercount)
972 # VL in Parallel-Reduce is the number of operations
974 # set up template in SVSHAPE0, then copy to 1. only 2 needed
975 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
976 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
977 mscale <- (0b0 || SVzd) + 1
978 SVSHAPE0[30:31] <- 0b10 # parallel reduce submode
980 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
981 # set up right operand (left operand 28:29 is zero)
982 SVSHAPE1[28:29] <- 0b01 # right operand
984 # set VL, MVL and Vertical-First
985 m[0:12] <- vlen * mscale
986 maxvl[0:6] <- m[6:12]
987 SVSTATE[0:6] <- maxvl # MAVXL
988 SVSTATE[7:13] <- vlen # VL
992 Special Registers Altered:
998 `svshape` is a convenience instruction that reduces instruction
999 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
1000 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
1001 including VL and MAXVL. Using `svshape` therefore does not also
1006 * **SVxd** - SV REMAP "xdim"
1007 * **SVyd** - SV REMAP "ydim"
1008 * **SVzd** - SV REMAP "zdim"
1009 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
1010 * **vf** - sets "Vertical-First" mode
1011 * **XO** - standard 6-bit XO field
1013 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
1014 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
1016 There are 12 REMAP Modes (2 Modes are RESERVED for `svshape2`, 2 Modes
1019 | SVRM | Remap Mode description |
1021 | 0b0000 | Matrix 1/2/3D |
1022 | 0b0001 | FFT Butterfly |
1023 | 0b0010 | reserved |
1024 | 0b0011 | DCT Outer butterfly |
1025 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1026 | 0b0101 | DCT COS table index generation |
1027 | 0b0110 | DCT half-swap |
1028 | 0b0111 | Parallel Reduction |
1029 | 0b1000 | reserved for svshape2 |
1030 | 0b1001 | reserved for svshape2 |
1031 | 0b1010 | reserved |
1032 | 0b1011 | iDCT Outer butterfly |
1033 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1034 | 0b1101 | iDCT COS table index generation |
1035 | 0b1110 | iDCT half-swap |
1036 | 0b1111 | FFT half-swap |
1038 Examples showing how all of these Modes operate exists in the online
1039 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD). Explaining
1040 these Modes further in detail is beyond the scope of this document.
1042 In Indexed Mode, there are only 5 bits available to specify the GPR
1043 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
1044 5 bits are given in the `SVxd` field: the bottom two implicit bits
1045 will be zero (`SVxd || 0b00`).
1047 `svshape` has *limited applicability* due to being a 32-bit instruction.
1048 The full capability of SVSHAPE SPRs may be accessed by directly writing
1049 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
1050 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
1051 instruction, `psvshape`, may extend the capability here.
1053 *Architectural Resource Allocation note: the SVRM field is carefully
1054 crafted to allocate two Modes, corresponding to bits 21-23 within the
1055 instruction being set to the value `0b100`, to `svshape2` (not
1056 `svshape`). These two Modes are
1057 considered "RESERVED" within the context of `svshape` but it is
1058 absolutely critical to allocate the exact same pattern in XO for
1059 both instructions in bits 26-31.*
1066 # svindex instruction <a name="svindex"> </a>
1070 | 0:5|6:10 |11:15 |16:20 | 21:25 | 26:31 | Form |
1071 | -- | -- | --- | ---- | ----------- | ------| -------- |
1072 | PO | SVG | rmm | SVd | ew/yx/mm/sk | XO | SVI-Form |
1074 * svindex SVG,rmm,SVd,ew,SVyx,mm,sk
1079 # based on nearest MAXVL compute other dimension
1083 do while d*dim <u ([0]*4 || MVL)
1086 # set up template, then copy once location identified
1088 shape[30:31] <- 0b00 # mode
1090 shape[18:20] <- 0b110 # indexed xd/yd
1091 shape[0:5] <- (0b0 || SVd) # xdim
1092 if sk = 0 then shape[6:11] <- 0 # ydim
1093 else shape[6:11] <- 0b111111 # ydim max
1095 shape[18:20] <- 0b111 # indexed yd/xd
1096 if sk = 1 then shape[6:11] <- 0 # ydim
1097 else shape[6:11] <- d-1 # ydim max
1098 shape[0:5] <- (0b0 || SVd) # ydim
1099 shape[12:17] <- (0b0 || SVG) # SVGPR
1100 shape[28:29] <- ew # element-width override
1101 shape[21] <- sk # skip 1st dimension
1103 # select the mode for updating SVSHAPEs
1104 SVSTATE[62] <- mm # set or clear persistence
1106 # clear out all SVSHAPEs first
1107 SVSHAPE0[0:31] <- [0] * 32
1108 SVSHAPE1[0:31] <- [0] * 32
1109 SVSHAPE2[0:31] <- [0] * 32
1110 SVSHAPE3[0:31] <- [0] * 32
1111 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1112 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1116 # activate requested shape
1117 if idx = 0 then SVSHAPE0 <- shape
1118 if idx = 1 then SVSHAPE1 <- shape
1119 if idx = 2 then SVSHAPE2 <- shape
1120 if idx = 3 then SVSHAPE3 <- shape
1121 SVSTATE[bit*2+32:bit*2+33] <- idx
1122 # increment shape index, modulo 4
1123 if idx = 3 then idx <- 0
1126 # refined SVSHAPE/REMAP update mode
1129 if idx = 0 then SVSHAPE0 <- shape
1130 if idx = 1 then SVSHAPE1 <- shape
1131 if idx = 2 then SVSHAPE2 <- shape
1132 if idx = 3 then SVSHAPE3 <- shape
1133 SVSTATE[bit*2+32:bit*2+33] <- idx
1134 SVSTATE[46-bit] <- 1
1137 Special Registers Altered:
1143 `svindex` is a convenience instruction that reduces instruction count
1144 for Indexed REMAP Mode. It sets up (overwrites) all required SVSHAPE
1145 SPRs and **unlike** `svshape` can modify the REMAP area of the SVSTATE
1146 SPR as well, including setting persistence. The relevant SPRs *may*
1147 be directly programmed with `mtspr` however it is laborious to do so:
1148 svindex saves instructions covering much of Indexed REMAP capability.
1152 * **SVd** - SV REMAP x/y dim
1153 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
1155 * **ew** - sets element width override on the Indices
1156 * **SVG** - GPR SVG<<2 to be used for Indexing
1157 * **yx** - 2D reordering to be used if yx=1
1158 * **mm** - mask mode. determines how `rmm` is interpreted.
1159 * **sk** - Dimension skipping enabled
1161 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
1162 "off-by-one". In the assembler
1163 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
1165 *Note: when `yx=1,sk=0` the second dimension is calculated as
1170 * `rmm`, like REMAP.SVme, has bit 0
1171 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
1172 bit 3 to mo0 and bit 4 to mi1
1173 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
1174 * for each bit set in the 5-bit `rmm`, in order, the first
1175 as-yet-unset SVSHAPE will be updated
1176 with the other operands in the instruction, and the REMAP
1178 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
1179 * SVSTATE persistence bit is cleared
1180 * No other alterations to SVSTATE are carried out
1182 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
1183 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
1184 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
1185 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
1187 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
1188 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
1189 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
1191 Rough algorithmic form:
1194 marray = [mi0, mi1, mi2, mo0, mo1]
1197 if not rmm[bit]: continue
1199 SVSTATE{marray[bit]} = idx
1200 idx = (idx+1) modulo 4
1205 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
1206 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
1208 * only the selected SVSHAPE is overwritten
1209 * only the relevant bits in the REMAP area of SVSTATE are updated
1210 * REMAP persistence bit is set.
1212 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
1213 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
1214 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
1215 set to 2 (SVSHAPE2).
1217 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
1218 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
1219 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
1220 set to 3 (SVSHAPE3).
1222 Rough algorithmic form:
1225 marray = [mi0, mi1, mi2, mo0, mo1]
1229 SVSTATE{marray[bit]} = idx
1233 In essence, `mm=0` is intended for use to set as much of the
1234 REMAP State SPRs as practical with a single instruction,
1235 whilst `mm=1` is intended to be a little more refined.
1237 **Usage guidelines**
1239 * **Disable 2D mapping**: to only perform Indexing without
1240 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
1242 * **Modulo 1D mapping**: to perform Indexing cycling through the
1243 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
1244 no requirement to set VL equal to a multiple of N.
1245 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
1246 `xdim=M,ydim=CEIL(MAXVL/M)`.
1248 Beyond these mappings it becomes necessary to write directly to
1249 the SVSTATE SPRs manually.
1256 # svshape2 (offset-priority) <a name="svshape2"> </a>
1260 | 0:5|6:9 |10|11:15 |16:20 | 21:24 | 25 | 26:31 | Form |
1261 | -- |----|--| --- | ----- | ------ | -- | ------| -------- |
1262 | PO |offs|yx| rmm | SVd | 100/mm | sk | XO | SVM2-Form |
1264 * svshape2 offs,yx,rmm,SVd,sk,mm
1269 # based on nearest MAXVL compute other dimension
1273 do while d*dim <u ([0]*4 || MVL)
1275 # set up template, then copy once location identified
1277 shape[30:31] <- 0b00 # mode
1278 shape[0:5] <- (0b0 || SVd) # x/ydim
1280 shape[18:20] <- 0b000 # ordering xd/yd(/zd)
1281 if sk = 0 then shape[6:11] <- 0 # ydim
1282 else shape[6:11] <- 0b111111 # ydim max
1284 shape[18:20] <- 0b010 # ordering yd/xd(/zd)
1285 if sk = 1 then shape[6:11] <- 0 # ydim
1286 else shape[6:11] <- d-1 # ydim max
1287 # offset (the prime purpose of this instruction)
1288 shape[24:27] <- SVo # offset
1289 if sk = 1 then shape[28:29] <- 0b01 # skip 1st dimension
1290 else shape[28:29] <- 0b00 # no skipping
1291 # select the mode for updating SVSHAPEs
1292 SVSTATE[62] <- mm # set or clear persistence
1294 # clear out all SVSHAPEs first
1295 SVSHAPE0[0:31] <- [0] * 32
1296 SVSHAPE1[0:31] <- [0] * 32
1297 SVSHAPE2[0:31] <- [0] * 32
1298 SVSHAPE3[0:31] <- [0] * 32
1299 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1300 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1304 # activate requested shape
1305 if idx = 0 then SVSHAPE0 <- shape
1306 if idx = 1 then SVSHAPE1 <- shape
1307 if idx = 2 then SVSHAPE2 <- shape
1308 if idx = 3 then SVSHAPE3 <- shape
1309 SVSTATE[bit*2+32:bit*2+33] <- idx
1310 # increment shape index, modulo 4
1311 if idx = 3 then idx <- 0
1314 # refined SVSHAPE/REMAP update mode
1317 if idx = 0 then SVSHAPE0 <- shape
1318 if idx = 1 then SVSHAPE1 <- shape
1319 if idx = 2 then SVSHAPE2 <- shape
1320 if idx = 3 then SVSHAPE3 <- shape
1321 SVSTATE[bit*2+32:bit*2+33] <- idx
1322 SVSTATE[46-bit] <- 1
1325 Special Registers Altered:
1331 `svshape2` is an additional convenience instruction that prioritises
1332 setting `SVSHAPE.offset`. Its primary purpose is for use when
1333 element-width overrides are used. It has identical capabilities to `svindex` and
1334 in terms of both options (skip, etc.) and ability to activate REMAP
1335 (rmm, mask mode) but unlike `svindex` it does not set GPR REMAP,
1336 only a 1D or 2D `svshape`, and
1337 unlike `svshape` it can set an arbirrary `SVSHAPE.offset` immediate.
1339 One of the limitations of Simple-V is that Vector elements start on the boundary
1340 of the Scalar regfile, which is fine when element-width overrides are not
1341 needed. If the starting point of a Vector with smaller elwidths must begin
1342 in the middle of a register, normally there would be no way to do so except
1343 through LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`is
1348 * **offs** (4 bits) - unsigned offset
1349 * **yx** (1 bit) - swap XY to YX
1350 * **SVd** dimension size
1351 * **rmm** REMAP mask
1353 * **sk** (1 bit) skips 1st dimension if set
1355 Dimensions are calculated exactly as `svindex`. `rmm` and
1356 `mm` are as per `svindex`.
1358 *Programmer's Note: offsets for `svshape2` may be specified in the range
1359 0-15. Given that the principle of Simple-V is to fit on top of
1360 byte-addressable register files and that GPR and FPR are 64-bit (8 bytes)
1361 it should be clear that the offset may, when `elwidth=8`, begin an
1362 element-level operation starting element zero at any arbitrary byte.
1363 On cursory examination attempting to go beyond the range 0-7 seems
1364 unnecessary given that the **next GPR or FPR** is an
1365 alias for an offset in the range 8-15. Thus by simply increasing
1366 the starting Vector point of the operation to the next register it
1367 can be seen that the offset of 0-7 would be sufficient. Unfortunately
1368 however some operations are EXTRA2-encoded it is **not possible**
1369 to increase the GPR/FPR register number by one, because EXTRA2-encoding
1370 of GPR/FPR Vector numbers are restricted to even numbering.
1371 For CR Fields the EXTRA2 encoding is even more sparse.
1372 The additional offset range (8-15) helps overcome these limitations.*
1374 *Hardware Implementor's note: with the offsets only being immediates
1375 and with register numbering being entirely immediate as well it is
1376 possible to correctly compute Register Hazards without requiring
1377 reading the contents of any SPRs. If however there are
1378 instructions that have directly written to the SVSTATE or SVSHAPE
1379 SPRs and those instructions are still in-flight then this position
1380 is clearly **invalid**. This is why Programmers are strongly
1381 discouraged from directly writing to these SPRs.*
1383 *Architectural Resource Allocation note: this instruction shares
1384 the space of `svshape`. Therefore it is critical that the two
1385 instructions, `svshape` and `svshape2` have the exact same XO
1386 in bits 26 thru 31. It is also critical that for `svshape2`,
1387 bit 21 of XO is a 1, bit 22 of XO is a 0, and bit 23 of XO is a 0.*