1 # RFC ls009 SVP64 REMAP instructions
5 * <https://libre-soc.org/openpower/sv/>
6 * <https://libre-soc.org/openpower/sv/rfc/ls009/>
7 * <https://bugs.libre-soc.org/show_bug.cgi?id=1042>
8 * <https://git.openpower.foundation/isa/PowerISA/issues/87>
20 **Books and Section affected**:
23 Book I, new Zero-Overhead-Loop Chapter.
24 Appendix E Power ISA sorted by opcode
25 Appendix F Power ISA sorted by version
26 Appendix G Power ISA sorted by Compliancy Subset
27 Appendix H Power ISA sorted by mnemonic
33 svremap - Re-Mapping of Register Element Offsets
34 svindex - General-purpose setting of SHAPEs to be re-mapped
35 svshape - Hardware-level setting of SHAPEs for element re-mapping
36 svshape2 - Hardware-level setting of SHAPEs for element re-mapping (v2)
39 **Submitter**: Luke Leighton (Libre-SOC)
41 **Requester**: Libre-SOC
43 **Impact on processor**:
46 Addition of four new "Zero-Overhead-Loop-Control" DSP-style Vector-style
47 Management Instructions which provide advanced features such as Matrix
48 FFT DCT Hardware-Assist Schedules and general-purpose Index reordering.
51 **Impact on software**:
54 Requires support for new instructions in assembler, debuggers,
61 Cray Supercomputing, Vectorisation, Zero-Overhead-Loop-Control (ZOLC),
62 Scalable Vectors, Multi-Issue Out-of-Order, Sequential Programming Model,
63 Digital Signal Processing (DSP)
68 These REMAP Management instructions provide state-of-the-art advanced capabilities
69 to dramatically decrease instruction count and power reduction whilst retaining
70 unprecedented general-purpose capability and a standard Sequential Execution Model.
72 **Notes and Observations**:
78 Add the following entries to:
80 * the Appendices of Book I
81 * Instructions of Book I as a new Section
82 * TODO-Form of Book I Section 1.6.1.6 and 1.6.2
91 # REMAP <a name="remap" />
93 * see [[sv/propagation]] for a future way to apply REMAP
95 REMAP is an advanced form of Vector "Structure Packing" that
96 provides hardware-level support for commonly-used *nested* loop patterns.
97 For more general reordering an Indexed REMAP mode is available.
99 REMAP allows the usual vector loop `0..VL-1` to be "reshaped" (re-mapped)
100 from a linear form to a 2D or 3D transposed form, or "offset" to permit
101 arbitrary access to elements (when elwidth overrides are used),
102 independently on each Vector src or dest
105 The initial primary motivation of REMAP was for Matrix Multiplication, reordering of sequential
106 data in-place: in-place DCT and FFT were easily justified given the
107 high usage in Computer Science.
108 Four SPRs are provided which may be applied to any GPR, FPR or CR Field
109 so that for example a single FMAC may be
110 used in a single loop to perform 5x3 times 3x4 Matrix multiplication,
111 generating 60 FMACs *without needing explicit assembler unrolling*.
112 Additional uses include regular "Structure Packing"
113 such as RGB pixel data extraction and reforming.
115 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
116 Vector ISAs which would typically only have a limited set of instructions
117 that can be structure-packed (LD/ST typically), REMAP may be applied to
118 literally any instruction: CRs, Arithmetic, Logical, LD/ST, anything.
120 Note that REMAP does not *directly* apply to sub-vector elements: that
121 is what swizzle is for. Swizzle *can* however be applied to the same
122 instruction as REMAP. As explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack EXTRA Mode bits
123 can extend down into Sub-vector elements to perform vec2/vec3/vec4
124 sequential reordering, but even here, REMAP is not extended down to
125 the actual sub-vector elements themselves.
127 In its general form, REMAP is quite expensive to set up, and on some
128 implementations may introduce
129 latency, so should realistically be used only where it is worthwhile.
130 Commonly-used patterns such as Matrix Multiply, DCT and FFT have
131 helper instruction options which make REMAP easier to use.
133 There are four types of REMAP:
135 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
136 Matrix transpose and rotate. The Shapes are set up for an "Outer Product"
138 * **FFT/DCT**, with full triple-loop in-place support: limited to
140 * **Indexing**, for any general-purpose reordering, also includes
141 limited 2D reshaping.
142 * **Parallel Reduction**, for scheduling a sequence of operations
143 in a Deterministic fashion, in a way that may be parallelised,
144 to reduce a Vector down to a single value.
146 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
147 REMAP Schedules are 100% Deterministic **including Indexing** and are
148 designed to be incorporated in between the Decode and Issue phases,
149 directly into Register Hazard Management.
151 Parallel Reduction is unusual in that it requires a full vector array
152 of results (not a scalar) and uses the rest of the result Vector for
153 the purposes of storing intermediary calculations. As these intermediary
154 results are Deterministically computed they may be useful.
155 Additionally, because the intermediate results are always written out
156 it is possible to service Precise Interrupts without affecting latency
157 (a common limitation of Vector ISAs).
161 * normal vector element read/write of operands would be sequential
163 * this is not appropriate for (e.g.) Matrix multiply which requires
164 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
165 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
166 with this. both are expensive (copy large vectors, spill through memory)
167 and very few Packed SIMD ISAs cope with non-Power-2.
168 * REMAP **redefines** the order of access according to set
169 (Deterministic) "Schedules".
170 * The Schedules are not at all restricted to power-of-two boundaries
171 making it unnecessary to have for example specialised 3x4 transpose
172 instructions of other Vector ISAs.
174 Only the most commonly-used algorithms in computer science have REMAP
175 support, due to the high cost in both the ISA and in hardware. For
176 arbitrary remapping the `Indexed` REMAP may be used.
180 * `svshape` to set the type of reordering to be applied to an
181 otherwise usual `0..VL-1` hardware for-loop
182 * `svremap` to set which registers a given reordering is to apply to
184 * `sv.{instruction}` where any Vectorised register marked by `svremap`
185 will have its ordering REMAPPED according to the schedule set
188 The following illustrative example multiplies a 3x4 and a 5x3
192 svshape 5, 4, 3, 0, 0
193 svremap 15, 1, 2, 3, 0, 0, 0, 0
194 sv.fmadds *0, *8, *16, *0
196 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
197 * svremap activates four out of five registers RA RB RC RT RS (15)
203 - RS Remapping to not be activated
204 * sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
205 * With REMAP being active each register's element index is
206 *independently* transformed using the specified SHAPEs.
208 Thus the Vector Loop is arranged such that the use of
209 the multiply-and-accumulate instruction executes precisely the required
210 Schedule to perform an in-place in-registers Matrix Multiply with no
211 need to perform additional Transpose or register copy instructions.
212 The example above may be executed as a unit test and demo,
213 [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)
217 This section summarises the motivation for each REMAP Schedule
218 and briefly goes over their characteristics and limitations.
219 Further details on the Deterministic Precise-Interruptible algorithms
220 used in these Schedules is found in the [[sv/remap/appendix]].
222 ## Matrix (1D/2D/3D shaping)
224 Matrix Multiplication is a huge part of High-Performance Compute,
226 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
227 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
228 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
229 Aside from the cost of the load on the L1 I-Cache, the trick only
230 works if one of the dimensions X or Y are power-two. Prime Numbers
231 (5x7, 3x5) become deeply problematic to unroll.
233 Even traditional Scalable Vector ISAs have issues with Matrices, often
234 having to perform data Transpose by pushing out through Memory and back,
235 or computing Transposition Indices (costly) then copying to another
238 Matrix REMAP was thus designed to solve these issues by providing Hardware
240 "Schedules" that can view what would otherwise be limited to a strictly
241 linear Vector as instead being 2D (even 3D) *in-place* reordered.
242 With both Transposition and non-power-two being supported the issues
243 faced by other ISAs are mitigated.
245 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
246 restricted to 127: up to 127 FMAs (or other operation)
247 may be performed in total.
248 Also given that it is in-registers only at present some care has to be
249 taken on regfile resource utilisation. However it is perfectly possible
250 to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
251 the usual 6-level large Matrix Multiply, without the usual difficulties
252 associated with SIMD.
254 Also the `svshape` instruction only provides access to part of the
255 Matrix REMAP capability. Rotation and mirroring need to be done by
256 programming the SVSHAPE SPRs directly, which can take a lot more
259 ## FFT/DCT Triple Loop
261 DCT and FFT are some of the most astonishingly used algorithms in
262 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
263 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
266 An in-depth analysis showed that it is possible to do in-place in-register
267 DCT and FFT as long as twin-result "butterfly" instructions are provided.
268 These can be found in the [[openpower/isa/svfparith]] page if performing
269 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
270 integer operations would be required)*. These "butterfly" instructions
271 avoid the need for a temporary register because the two array positions
272 being overwritten will be "in-flight" in any In-Order or Out-of-Order
275 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
276 accept predicate masks. Given that it is common to perform recursive
277 convolutions combining smaller Power-2 DCT/FFT to create larger DCT/FFTs
278 in practice the RADIX2 limit is not a problem. A Bluestein convolution
279 to compute arbitrary length is demonstrated by
280 [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
284 The purpose of Indexing is to provide a generalised version of
285 Vector ISA "Permute" instructions, such as VSX `vperm`. The
286 Indexing is abstracted out and may be applied to much more
287 than an element move/copy, and is not limited for example
288 to the number of bytes that can fit into a VSX register.
289 Indexing may be applied to LD/ST (even on Indexed LD/ST
290 instructions such as `sv.lbzx`), arithmetic operations,
291 extsw: there is no artificial limit.
293 The only major caveat is that the registers to be used as
294 Indices must not be modified by any instruction after Indexed Mode
295 is established, and neither must MAXVL be altered. Additionally,
296 no register used as an Index may exceed MAXVL-1.
299 these conditions results in `UNDEFINED` behaviour.
300 These conditions allow a Read-After-Write (RAW) Hazard to be created on
301 the entire range of Indices to be subsequently used, but a corresponding
302 Write-After-Read Hazard by any instruction that modifies the Indices
303 **does not have to be created**. Given the large number of registers
304 involved in Indexing this is a huge resource saving and reduction
305 in micro-architectural complexity. MAXVL is likewise
306 included in the RAW Hazards because it is involved in calculating
307 how many registers are to be considered Indices.
309 With these Hazard Mitigations in place, high-performance implementations
310 may read-cache the Indices from the point where a given `svindex` instruction
311 is called (or SVSHAPE SPRs - and MAXVL- directly altered).
313 The original motivation for Indexed REMAP was to mitigate the need to add
314 an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
315 a stand-alone instruction. Usually a Vector ISA would add a non-conflicting
316 variant (as in VSX `vperm`) but it is common to need to permute by source,
317 with the risk of conflict, that has to be resolved, for example, in AVX-512
320 Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
321 destinations), which on a superficial analysis may be perceived to be a
322 problem, until it is recalled that, firstly, Simple-V is designed specifically
323 to require Program Order to be respected, and that Matrix, DCT and FFT
324 all *already* critically depend on overlapping Reads/Writes: Matrix
325 uses overlapping registers as accumulators. Thus the Register Hazard
326 Management needed by Indexed REMAP *has* to be in place anyway.
328 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
329 clearly that of the additional reading of the GPRs to be used as Indices,
330 plus the setup cost associated with creating those same Indices.
331 If any Deterministic REMAP can cover the required task, clearly it
332 is adviseable to use it instead.
334 *Programmer's note: some algorithms may require skipping of Indices exceeding
335 VL-1, not MAXVL-1. This may be achieved programmatically by performing
336 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
337 and RB contains the value of VL returned from `setvl`. The resultant
338 CR Fields may then be used as Predicate Masks to exclude those operations
339 with an Index exceeding VL-1.*
341 ## Parallel Reduction
343 Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
344 (Power ISA v3.0B) operation is leveraged, unmodified, to give the
345 *appearance* and *effect* of Reduction.
347 In Horizontal-First Mode, Vector-result reduction **requires**
348 the destination to be a Vector, which will be used to store
349 intermediary results.
351 Given that the tree-reduction schedule is deterministic,
352 Interrupts and exceptions
353 can therefore also be precise. The final result will be in the first
354 non-predicate-masked-out destination element, but due again to
355 the deterministic schedule programmers may find uses for the intermediate
358 When Rc=1 a corresponding Vector of co-resultant CRs is also
359 created. No special action is taken: the result and its CR Field
360 are stored "as usual" exactly as all other SVP64 Rc=1 operations.
362 Note that the Schedule only makes sense on top of certain instructions:
363 X-Form with a Register Profile of `RT,RA,RB` is fine because two sources
364 and the destination are all the same type. Like Scalar
365 Reduction, nothing is prohibited:
366 the results of execution on an unsuitable instruction may simply
367 not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
370 Critical to note regarding use of Parallel-Reduction REMAP is that,
371 exactly as with all REMAP Modes, the `svshape` instruction *requests*
372 a certain Vector Length (number of elements to reduce) and then
373 sets VL and MAXVL at the number of **operations** needed to be
374 carried out. Thus, equally as importantly, like Matrix REMAP
375 the total number of operations
376 is restricted to 127. Any Parallel-Reduction requiring more operations
377 will need to be done manually in batches (hierarchical
378 recursive Reduction).
380 Also important to note is that the Deterministic Schedule is arranged
381 so that some implementations *may* parallelise it (as long as doing so
382 respects Program Order and Register Hazards). Performance (speed)
384 implementation is neither strictly defined or guaranteed. As with
385 the Vulkan(tm) Specification, strict compliance is paramount whilst
386 performance is at the discretion of Implementors.
388 **Parallel-Reduction with Predication**
390 To avoid breaking the strict RISC-paradigm, keeping the Issue-Schedule
391 completely separate from the actual element-level (scalar) operations,
392 Move operations are **not** included in the Schedule. This means that
393 the Schedule leaves the final (scalar) result in the first-non-masked
394 element of the Vector used. With the predicate mask being dynamic
395 (but deterministic) this result could be anywhere.
397 If that result is needed to be moved to a (single) scalar register
398 then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
399 needed to get it, where the predicate is the exact same predicate used
400 in the prior Parallel-Reduction instruction.
402 * If there was only a single
403 bit in the predicate then the result will not have moved or been altered
404 from the source vector prior to the Reduction
405 * If there was more than one bit the result will be in the
406 first element with a predicate bit set.
408 In either case the result is in the element with the first bit set in
411 For *some* implementations
412 the vector-to-scalar copy may be a slow operation, as may the Predicated
413 Parallel Reduction itself.
414 It may be better to perform a pre-copy
415 of the values, compressing them (VREDUCE-style) into a contiguous block,
416 which will guarantee that the result goes into the very first element
417 of the destination vector, in which case clearly no follow-up
418 vector-to-scalar MV operation is needed.
422 The simplest usage is to perform an overwrite, specifying all three
423 register operands the same.
425 svshape parallelreduce, 6
428 The Reduction Schedule will issue the Parallel Tree Reduction spanning
429 registers 8 through 13, by adjusting the offsets to RT, RA and RB as
430 necessary (see "Parallel Reduction algorithm" in a later section).
432 A non-overwrite is possible as well but just as with the overwrite
433 version, only those destination elements necessary for storing
434 intermediary computations will be written to: the remaining elements
435 will **not** be overwritten and will **not** be zero'd.
437 svshape parallelreduce, 6
440 However it is critical to note that if the source and destination are
441 not the same then the trick of using a follow-up vector-scalar MV will
444 ## Sub-Vector Horizontal Reduction
446 Note that when SVM is clear and SUBVL!=1 a Parallel Reduction is performed
447 on all first Subvector elements, followed by another separate independent
448 Parallel Reduction on all the second Subvector elements and so on.
450 for selectsubelement in (x,y,z,w):
451 parallelreduce(0..VL-1, selectsubelement)
453 By contrast, when SVM is set and SUBVL!=1, a Horizontal
454 Subvector mode is enabled, applying the Parallel Reduction
455 Algorithm to the Subvector Elements. The Parallel Reduction
456 is independently applied VL times, to each group of Subvector
457 elements. Bear in mind that predication is never applied down
458 into individual Subvector elements, but will be applied
459 to select whether the *entire* Parallel Reduction on each
460 group is performed or not.
462 Â for (i = 0; i < VL; i++)
463 if (predval & 1<<i) # predication
465 parallelreduction([el.x, el.y, el.z, el.w])
467 Note that as this is a Parallel Reduction, for best results
468 it should be an overwrite operation, where the result for
469 the Horizontal Reduction of each Subvector will be in the
470 first Subvector element.
471 Also note that use of Rc=1 is `UNDEFINED` behaviour.
473 In essence what is happening here is that Structure Packing is being
474 combined with Parallel Reduction. If the Subvector elements may be
475 laid out as a 2D matrix, with the Subvector elements on rows,
476 and Parallel Reduction is applied per row, then if `SVM` is **clear**
477 the Matrix is transposed (like Pack/Unpack)
478 before still applying the Parallel Reduction to the **row**.
480 # Determining Register Hazards
482 For high-performance (Multi-Issue, Out-of-Order) systems it is critical
483 to be able to statically determine the extent of Vectors in order to
484 allocate pre-emptive Hazard protection. The next task is to eliminate
485 masked-out elements using predicate bits, freeing up the associated
488 For non-REMAP situations `VL` is sufficient to ascertain early
489 Hazard coverage, and with SVSTATE being a high priority cached
490 quantity at the same level of MSR and PC this is not a problem.
492 The problems come when REMAP is enabled. Indexed REMAP must instead
493 use `MAXVL` as the earliest (simplest)
494 batch-level Hazard Reservation indicator,
495 but Matrix, FFT and Parallel Reduction must all use completely different
496 schemes. The reason is that VL is used to step through the total
497 number of *operations*, not the number of registers. The "Saving Grace"
498 is that all of the REMAP Schedules are Deterministic.
500 Advance-notice Parallel computation and subsequent cacheing
501 of all of these complex Deterministic REMAP Schedules is
502 *strongly recommended*, thus allowing clear and precise multi-issue
503 batched Hazard coverage to be deployed, *even for Indexed Mode*.
504 This is only possible for Indexed due to the strict guidelines
505 given to Programmers.
507 In short, there exists solutions to the problem of Hazard Management,
508 with varying degrees of refinement possible at correspondingly
509 increasing levels of complexity in hardware.
511 # REMAP area of SVSTATE
513 The following bits of the SVSTATE SPR are used for REMAP:
515 |32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
516 | -- | -- | -- | -- | -- | ----- | ------ |
517 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
519 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
520 mi0-2 apply to RA, RB, RC respectively, as input registers, and
521 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
522 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
523 SVSHAPE is actively applied or not.
525 * bit 0 of SVme indicates if mi0 is applied to RA / FRA
526 * bit 1 of SVme indicates if mi1 is applied to RB / FRB
527 * bit 2 of SVme indicates if mi2 is applied to RC / FRC
528 * bit 3 of SVme indicates if mo0 is applied to RT / FRT
529 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
530 (LD/ST-with-update has an implicit 2nd write register, RA)
532 # svremap instruction <a name="svremap"> </a>
534 There is also a corresponding SVRM-Form for the svremap
535 instruction which matches the above SPR:
537 svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
539 |0 |6 |11 |13 |15 |17 |19 |21 | 22.25 |26..31 |
540 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
541 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
543 # SHAPE Remapping SPRs
545 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
546 which have the same format.
548 Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
549 disabled: the register's elements are a linear (1D) vector.
551 |31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
552 |---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
553 |0b00 |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
554 |0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
555 |0b01 |submode|offset| invxyz | submode2| zdimsz |mode |xdimsz|DCT/FFT|
556 |0b10 |submode|offset| invxyz | rsvd | rsvd |rsvd |xdimsz|Preduce|
557 |0b11 | | | | | | | |rsvd |
559 mode sets different behaviours (straight matrix multiply, FFT, DCT).
561 * **mode=0b00** sets straight Matrix Mode
562 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
563 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
564 * **mode=0b10** sets "Parallel Reduction" Schedules.
566 ## Parallel Reduction Mode
568 Creates the Schedules for Parallel Tree Reduction.
570 * **submode=0b00** selects the left operand index
571 * **submode=0b01** selects the right operand index
573 * When bit 0 of `invxyz` is set, the order of the indices
574 in the inner for-loop are reversed. This has the side-effect
575 of placing the final reduced result in the last-predicated element.
576 It also has the indirect side-effect of swapping the source
577 registers: Left-operand index numbers will always exceed
578 Right-operand indices.
579 When clear, the reduced result will be in the first-predicated
580 element, and Left-operand indices will always be *less* than
582 * When bit 1 of `invxyz` is set, the order of the outer loop
583 step is inverted: stepping begins at the nearest power-of two
584 to half of the vector length and reduces by half each time.
585 When clear the step will begin at 2 and double on each
590 submode2=0 is for FFT. For FFT submode the following schedules may be
593 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
595 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
597 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
599 When submode2 is 1 or 2, for DCT inner butterfly submode the following
600 schedules may be selected. When submode2 is 1, additional bit-reversing
603 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
605 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
606 in reverse-order, in-place
607 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
608 useful for calculating the cosine coefficient
609 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
610 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
612 When submode2 is 3 or 4, for DCT outer butterfly submode the following
613 schedules may be selected. When submode is 3, additional bit-reversing
616 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
617 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
619 `zdimsz` is used as an in-place "Stride", particularly useful for
620 column-based in-place DCT/FFT.
624 In Matrix Mode, skip allows dimensions to be skipped from being included
625 in the resultant output index. this allows sequences to be repeated:
626 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
627 modulo ```0 1 2 0 1 2 ...```
629 * **skip=0b00** indicates no dimensions to be skipped
630 * **skip=0b01** sets "skip 1st dimension"
631 * **skip=0b10** sets "skip 2nd dimension"
632 * **skip=0b11** sets "skip 3rd dimension"
634 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
635 zero then x-dimensional counting begins from 0 and increments, otherwise
636 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
638 offset will have the effect of offsetting the result by ```offset``` elements:
641 GPR(RT + remap(i) + SVSHAPE.offset) = ....
643 this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
644 bear in mind that unlike a static compiler SVSHAPE.offset may
645 be set dynamically at runtime.
647 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
648 that the array dimensionality for that dimension is 1. any dimension
649 not intended to be used must have its value set to 0 (dimensionality
650 of 1). A value of xdimsz=2 would indicate that in the first dimension
651 there are 3 elements in the array. For example, to create a 2D array
652 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
654 The format of the array is therefore as follows:
656 array[xdimsz+1][ydimsz+1][zdimsz+1]
658 However whilst illustrative of the dimensionality, that does not take the
659 "permute" setting into account. "permute" may be any one of six values
660 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
661 below shows how the permutation dimensionality order works:
663 | permute | order | array format |
664 | ------- | ----- | ------------------------ |
665 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
666 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
667 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
668 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
669 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
670 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
671 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
672 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
674 In other words, the "permute" option changes the order in which
675 nested for-loops over the array would be done. See executable
676 python reference code for further details.
678 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
681 With all these options it is possible to support in-place transpose,
682 in-place rotate, Matrix Multiply and Convolutions, without being
683 limited to Power-of-Two dimension sizes.
687 Indexed Mode activates reading of the element indices from the GPR
688 and includes optional limited 2D reordering.
689 In its simplest form (without elwidth overrides or other modes):
693 return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
696 element_result = ....
697 GPR(RT + indexed_remap(i)) = element_result
700 With element-width overrides included, and using the pseudocode
701 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
706 svreg = SVSHAPE.SVGPR << 1
707 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
708 offs = SVSHAPE.offset
709 return get_polymorphed_reg(svreg, srcwid, i) + offs
712 element_result = ....
713 rt_idx = indexed_remap(i)
714 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
717 Matrix-style reordering still applies to the indices, except limited
718 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
719 (Y,X). Only one dimension may optionally be skipped. Inversion of either
720 X or Y or both is possible. Pseudocode for Indexed Mode (including elwidth
721 overrides) may be written in terms of Matrix Mode, specifically
722 purposed to ensure that the 3rd dimension (Z) has no effect:
725 def index_remap(ISHAPE, i):
726 MSHAPE.skip = 0b0 || ISHAPE.sk1
727 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
728 MSHAPE.xdimsz = ISHAPE.xdimsz
729 MSHAPE.ydimsz = ISHAPE.ydimsz
730 MSHAPE.zdimsz = 0 # disabled
731 if ISHAPE.permute = 0b110 # 0,1
732 MSHAPE.permute = 0b000 # 0,1,2
733 if ISHAPE.permute = 0b111 # 1,0
734 MSHAPE.permute = 0b010 # 1,0,2
735 el_idx = remap_matrix(MSHAPE, i)
736 svreg = ISHAPE.SVGPR << 1
737 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
739 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
742 The most important observation above is that the Matrix-style
743 remapping occurs first and the Index lookup second. Thus it
744 becomes possible to perform in-place Transpose of Indices which
745 may have been costly to set up or costly to duplicate
746 (waste register file space).
748 # svshape instruction <a name="svshape"> </a>
750 `svshape` is a convenience instruction that reduces instruction
751 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
752 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
753 including VL and MAXVL. Using `svshape` therefore does not also
756 Form: SVM-Form SV "Matrix" Form (see [[isatables/fields.text]])
758 svshape SVxd,SVyd,SVzd,SVRM,vf
760 | 0.5|6.10 |11.15 |16..20 | 21..24 | 25 | 26..31| name |
761 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
762 |OPCD| SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
766 * **SVxd** - SV REMAP "xdim"
767 * **SVyd** - SV REMAP "ydim"
768 * **SVzd** - SV REMAP "zdim"
769 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
770 * **vf** - sets "Vertical-First" mode
771 * **XO** - standard 6-bit XO field
773 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
774 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
776 | SVRM | Remap Mode description |
778 | 0b0000 | Matrix 1/2/3D |
779 | 0b0001 | FFT Butterfly |
780 | 0b0010 | DCT Inner butterfly, pre-calculated coefficients |
781 | 0b0011 | DCT Outer butterfly |
782 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
783 | 0b0101 | DCT COS table index generation |
784 | 0b0110 | DCT half-swap |
785 | 0b0111 | Parallel Reduction |
786 | 0b1000 | reserved for svshape2 |
787 | 0b1001 | reserved for svshape2 |
788 | 0b1010 | iDCT Inner butterfly, pre-calculated coefficients |
789 | 0b1011 | iDCT Outer butterfly |
790 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
791 | 0b1101 | iDCT COS table index generation |
792 | 0b1110 | iDCT half-swap |
793 | 0b1111 | FFT half-swap |
795 Examples showing how all of these Modes operate exists in the online
796 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD)
797 and the full pseudocode setting up all SPRs
798 is in the [[openpower/isa/simplev]] page.
800 In Indexed Mode, there are only 5 bits available to specify the GPR
801 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
802 5 bits are given in the `SVxd` field: the bottom two implicit bits
803 will be zero (`SVxd || 0b00`).
805 `svshape` has *limited applicability* due to being a 32-bit instruction.
806 The full capability of SVSHAPE SPRs may be accessed by directly writing
807 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
808 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
809 instruction, `psvshape`, may extend the capability here.
811 # svindex instruction <a name="svindex"> </a>
813 `svindex` is a convenience instruction that reduces instruction
814 count for Indexed REMAP Mode. It sets up
815 (overwrites) all required SVSHAPE SPRs and can modify the REMAP
816 SPR as well. The relevant SPRs *may* be directly programmed with
817 `mtspr` however it is laborious to do so: svindex saves instructions
818 covering much of Indexed REMAP capability.
820 Form: SVI-Form SV "Indexed" Form (see [[isatables/fields.text]])
822 svindex SVG,rmm,SVd,ew,yx,mr,sk
824 | 0.5|6.10 |11.15 |16.20 | 21..25 | 26..31| name | Form |
825 | -- | -- | --- | ---- | ----------- | ------| -------- | ---- |
826 |OPCD| SVG | rmm | SVd | ew/yx/mm/sk | XO | svindex | SVI-Form |
830 * **SVd** - SV REMAP x/y dim
831 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
833 * **ew** - sets element width override on the Indices
834 * **SVG** - GPR SVG<<2 to be used for Indexing
835 * **yx** - 2D reordering to be used if yx=1
836 * **mm** - mask mode. determines how `rmm` is interpreted.
837 * **sk** - Dimension skipping enabled
838 * **XO** - standard 6-bit XO field
840 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
841 "off-by-one". In the assembler
842 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
844 *Note: when `yx=1,sk=0` the second dimension is calculated as
849 * `rmm`, like REMAP.SVme, has bit 0
850 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
851 bit 3 to mo0 and bit 4 to mi1
852 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
853 * for each bit set in the 5-bit `rmm`, in order, the first
854 as-yet-unset SVSHAPE will be updated
855 with the other operands in the instruction, and the REMAP
857 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
858 * SVSTATE persistence bit is cleared
859 * No other alterations to SVSTATE are carried out
861 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
862 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
863 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
864 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
866 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
867 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
868 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
870 Rough algorithmic form:
872 marray = [mi0, mi1, mi2, mo0, mo1]
875 if not rmm[bit]: continue
877 SVSTATE{marray[bit]} = idx
878 idx = (idx+1) modulo 4
882 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
883 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
885 * only the selected SVSHAPE is overwritten
886 * only the relevant bits in the REMAP area of SVSTATE are updated
887 * REMAP persistence bit is set.
889 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
890 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
891 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
894 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
895 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
896 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
899 Rough algorithmic form:
901 marray = [mi0, mi1, mi2, mo0, mo1]
905 SVSTATE{marray[bit]} = idx
908 In essence, `mm=0` is intended for use to set as much of the
909 REMAP State SPRs as practical with a single instruction,
910 whilst `mm=1` is intended to be a little more refined.
914 * **Disable 2D mapping**: to only perform Indexing without
915 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
917 * **Modulo 1D mapping**: to perform Indexing cycling through the
918 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
919 no requirement to set VL equal to a multiple of N.
920 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
921 `xdim=M,ydim=CEIL(MAXVL/M)`.
923 Beyond these mappings it becomes necessary to write directly to
924 the SVSTATE SPRs manually.
926 # svshape2 (offset) <a name="svshape2"> </a>
928 `svshape2` is an additional convenience instruction that prioritises
929 setting `SVSHAPE.offset`. Its primary purpose is for use when
930 element-width overrides are used. It has identical capabilities to `svindex` and
931 in terms of both options (skip, etc.) and ability to activate REMAP
932 (rmm, mask mode) but unlike `svindex` it does not set GPR REMAP,
933 only a 1D or 2D `svshape`, and
934 unlike `svshape` it can set an arbirrary `SVSHAPE.offset` immediate.
936 One of the limitations of Simple-V is that Vector elements start on the boundary
937 of the Scalar regfile, which is fine when element-width overrides are not
938 needed. If the starting point of a Vector with smaller elwidths must begin
939 in the middle of a register, normally there would be no way to do so except
940 through LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`is
943 svshape2 offs,yx,rmm,SVd,sk,mm
945 | 0.5|6..9|10|11.15 |16..20 | 21..25 | 25 | 26..31| name |
946 | -- |----|--| --- | ----- | ------ | -- | ------| -------- |
947 |OPCD|offs|yx| rmm | SVd | 100/mm | sk | XO | svshape |
949 * **offs** (4 bits) - unsigned offset
950 * **yx** (1 bit) - swap XY to YX
951 * **SVd** dimension size
954 * **sk** (1 bit) skips 1st dimension if set
956 Dimensions are calculated exactly as `svindex`. `rmm` and
957 `mm` are as per `svindex`.
959 *Programmer's Note: offsets for `svshape2` may be specified in the range
960 0-15. Given that the principle of Simple-V is to fit on top of
961 byte-addressable register files and that GPR and FPR are 64-bit (8 bytes)
962 it should be clear that the offset may, when `elwidth=8`, begin an
963 element-level operation starting element zero at any arbitrary byte.
964 On cursory examination attempting to go beyond the range 0-7 seems
965 unnecessary given that the **next GPR or FPR** is an
966 alias for an offset in the range 8-15. Thus by simply increasing
967 the starting Vector point of the operation to the next register it
968 can be seen that the offset of 0-7 would be sufficient. Unfortunately
969 however some operations are EXTRA2-encoded it is **not possible**
970 to increase the GPR/FPR register number by one, because EXTRA2-encoding
971 of GPR/FPR Vector numbers are restricted to even numbering.
972 For CR Fields the EXTRA2 encoding is even more sparse.
973 The additional offset range (8-15) helps overcome these limitations.*
975 *Hardware Implementor's note: with the offsets only being immediates
976 and with register numbering being entirely immediate as well it is
977 possible to correctly compute Register Hazards without requiring
978 reading the contents of any SPRs. If however there are
979 instructions that have directly written to the SVSTATE or SVSHAPE
980 SPRs and those instructions are still in-flight then this position
981 is clearly **invalid**.*
989 # svstep: Vertical-First Stepping and status reporting
993 * svstep RT,SVi,vf (Rc=0)
994 * svstep. RT,SVi,vf (Rc=1)
996 | 0-5|6-10|11.15|16..22| 23-25 | 26-30 |31| Form |
997 |----|----|-----|------|----------|-------|--|--------- |
998 |PO | RT | / | SVi | / / vf | XO |Rc| SVL-Form |
1003 if SVi[3:4] = 0b11 then
1004 # store pack and unpack in SVSTATE
1005 SVSTATE[53] <- SVi[5]
1006 SVSTATE[54] <- SVi[6]
1007 RT <- [0]*62 || SVSTATE[53:54]
1009 # Vertical-First explicit stepping.
1010 step <- SVSTATE_NEXT(SVi, vf)
1011 RT <- [0]*57 || step
1014 Special Registers Altered:
1032 Add the following to Book I, 1.6.1, SVI-Form
1035 |0 |6 |11 |16 |21 |23 |24|25|26 31|
1036 | PO | SVG|rmm | SVd |ew |SVyx|mm|sk| XO |
1039 Add the following to Book I, 1.6.1, SVM-Form
1042 |0 |6 |11 |16 |21 |25 |26 |31 |
1043 | PO | SVxd | SVyd | SVzd | SVrm |vf | XO |
1046 Add the following to Book I, 1.6.1, SVM2-Form
1049 # 1.6.35.1 SVM2-FORM
1050 |0 |6 |10 |11 |16 |21 |24|25 |26 |31 |
1051 | PO | SVo |SVyx| rmm | SVd |XO |mm|sk | XO |
1054 Add the following to Book I, 1.6.1, SVRM-Form
1058 |0 |6 |11 |13 |15 |17 |19 |21 |22 |26 |31 |
1059 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 |pst |/// | XO |
1062 * Add `SVI, SVM, SVM2, SVRM` to `XO (26:31)` Field in Book I, 1.6.2
1064 Add the following to Book I, 1.6.2
1068 Field used in REMAP to select the SVSHAPE for 1st input register
1071 Field used in REMAP to select the SVSHAPE for 2nd input register
1074 Field used in REMAP to select the SVSHAPE for 3rd input register
1077 Field used to specify the meaning of the rmm field for SVI-Form
1081 Field used in REMAP to select the SVSHAPE for 1st output register
1084 Field used in REMAP to select the SVSHAPE for 2nd output register
1087 Field used in REMAP to indicate "persistence" mode (REMAP
1088 continues to apply to multiple instructions)
1091 REMAP Mode field for SVI-Form and SVM2-Form
1094 Field used to specify dimensional skipping in svindex
1097 Immediate field used to specify the size of the REMAP dimension
1098 in the svindex and svshape2 instructions
1101 Immediate field used to specify a 9-bit signed
1102 two's complement integer which is concatenated
1103 on the right with 0b00 and sign-extended to 64 bits.
1106 Field used to specify a GPR to be used as a
1107 source for indexing.
1110 Simple-V immediate field for setting VL or MVL
1113 Simple-V "REMAP" map-enable bits (0-4)
1116 Field used by the svshape2 instruction as an offset
1119 Simple-V "REMAP" Mode
1122 Simple-V "REMAP" x-dimension size
1125 Simple-V "REMAP" y-dimension size
1128 Simple-V "REMAP" z-dimension size
1134 Appendix E Power ISA sorted by opcode
1135 Appendix F Power ISA sorted by version
1136 Appendix G Power ISA sorted by Compliancy Subset
1137 Appendix H Power ISA sorted by mnemonic
1139 | Form | Book | Page | Version | mnemonic | Description |
1140 |------|------|------|---------|----------|-------------|
1141 | SVRM | I | # | 3.0B | svremap | REMAP enabling instruction |