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 REMAP is an advanced form of Vector "Structure Packing" that
94 provides hardware-level support for commonly-used *nested* loop patterns.
95 For more general reordering an Indexed REMAP mode is available.
97 REMAP allows the usual vector loop `0..VL-1` to be "reshaped" (re-mapped)
98 from a linear form to a 2D or 3D transposed form, or "offset" to permit
99 arbitrary access to elements (when elwidth overrides are used),
100 independently on each Vector src or dest
101 register. Aside from Indexed REMAP this is entirely Hardware-accelerated
102 reordering and consequently not costly in terms of register access. It
103 will however place a burden on Multi-Issue systems but no more than if -
104 exactly as if - the equivalent Scalar instructions were explicitly
105 loop-unrolled without SVP64.
107 The initial primary motivation of REMAP was for Matrix Multiplication, reordering of sequential
108 data in-place: in-place DCT and FFT were easily justified given the
109 high usage in Computer Science.
110 Four SPRs are provided which may be applied to any GPR, FPR or CR Field
111 so that for example a single FMAC may be
112 used in a single loop to perform 5x3 times 3x4 Matrix multiplication,
113 generating 60 FMACs *without needing explicit assembler unrolling*.
114 Additional uses include regular "Structure Packing"
115 such as RGB pixel data extraction and reforming.
117 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
118 Vector ISAs which would typically only have a limited set of instructions
119 that can be structure-packed (LD/ST typically), REMAP may be applied to
120 literally any instruction: CRs, Arithmetic, Logical, LD/ST, anything.
122 Note that REMAP does not *directly* apply to sub-vector elements: that
123 is what swizzle is for. Swizzle *can* however be applied to the same
124 instruction as REMAP. As explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack EXTRA Mode bits
125 can extend down into Sub-vector elements to perform vec2/vec3/vec4
126 sequential reordering, but even here, REMAP is not extended down to
127 the actual sub-vector elements themselves.
129 In its general form, REMAP is quite expensive to set up, and on some
130 implementations may introduce
131 latency, so should realistically be used only where it is worthwhile.
132 Commonly-used patterns such as Matrix Multiply, DCT and FFT have
133 helper instruction options which make REMAP easier to use.
135 There are four types of REMAP:
137 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
138 Matrix transpose and rotate. The Shapes are set up for an "Outer Product"
140 * **FFT/DCT**, with full triple-loop in-place support: limited to
142 * **Indexing**, for any general-purpose reordering, also includes
143 limited 2D reshaping.
144 * **Parallel Reduction**, for scheduling a sequence of operations
145 in a Deterministic fashion, in a way that may be parallelised,
146 to reduce a Vector down to a single value.
148 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
149 REMAP Schedules are 100% Deterministic **including Indexing** and are
150 designed to be incorporated in between the Decode and Issue phases,
151 directly into Register Hazard Management.
153 Parallel Reduction is unusual in that it requires a full vector array
154 of results (not a scalar) and uses the rest of the result Vector for
155 the purposes of storing intermediary calculations. As these intermediary
156 results are Deterministically computed they may be useful.
157 Additionally, because the intermediate results are always written out
158 it is possible to service Precise Interrupts without affecting latency
159 (a common limitation of Vector ISAs implementing explicit
160 Parallel Reduction instructions).
164 * normal vector element read/write of operands would be sequential
166 * this is not appropriate for (e.g.) Matrix multiply which requires
167 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
168 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
169 with this. both are expensive (copy large vectors, spill through memory)
170 and very few Packed SIMD ISAs cope with non-Power-2.
171 * REMAP **redefines** the order of access according to set
172 (Deterministic) "Schedules".
173 * The Schedules are not at all restricted to power-of-two boundaries
174 making it unnecessary to have for example specialised 3x4 transpose
175 instructions of other Vector ISAs.
177 Only the most commonly-used algorithms in computer science have REMAP
178 support, due to the high cost in both the ISA and in hardware. For
179 arbitrary remapping the `Indexed` REMAP may be used.
183 * `svshape` to set the type of reordering to be applied to an
184 otherwise usual `0..VL-1` hardware for-loop
185 * `svremap` to set which registers a given reordering is to apply to
187 * `sv.{instruction}` where any Vectorised register marked by `svremap`
188 will have its ordering REMAPPED according to the schedule set
191 The following illustrative example multiplies a 3x4 and a 5x3
196 svshape 5, 4, 3, 0, 0
197 svremap 15, 1, 2, 3, 0, 0, 0, 0
198 sv.fmadds *0, *8, *16, *0
201 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
202 * svremap activates four out of five registers RA RB RC RT RS (15)
208 - RS Remapping to not be activated
209 * sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
210 * With REMAP being active each register's element index is
211 *independently* transformed using the specified SHAPEs.
213 Thus the Vector Loop is arranged such that the use of
214 the multiply-and-accumulate instruction executes precisely the required
215 Schedule to perform an in-place in-registers Matrix Multiply with no
216 need to perform additional Transpose or register copy instructions.
217 The example above may be executed as a unit test and demo,
218 [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)
222 This section summarises the motivation for each REMAP Schedule
223 and briefly goes over their characteristics and limitations.
224 Further details on the Deterministic Precise-Interruptible algorithms
225 used in these Schedules is found in the [[sv/remap/appendix]].
227 ### Matrix (1D/2D/3D shaping)
229 Matrix Multiplication is a huge part of High-Performance Compute,
231 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
232 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
233 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
234 Aside from the cost of the load on the L1 I-Cache, the trick only
235 works if one of the dimensions X or Y are power-two. Prime Numbers
236 (5x7, 3x5) become deeply problematic to unroll.
238 Even traditional Scalable Vector ISAs have issues with Matrices, often
239 having to perform data Transpose by pushing out through Memory and back,
240 or computing Transposition Indices (costly) then copying to another
243 Matrix REMAP was thus designed to solve these issues by providing Hardware
245 "Schedules" that can view what would otherwise be limited to a strictly
246 linear Vector as instead being 2D (even 3D) *in-place* reordered.
247 With both Transposition and non-power-two being supported the issues
248 faced by other ISAs are mitigated.
250 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
251 restricted to 127: up to 127 FMAs (or other operation)
252 may be performed in total.
253 Also given that it is in-registers only at present some care has to be
254 taken on regfile resource utilisation. However it is perfectly possible
255 to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
256 the usual 6-level large Matrix Multiply, without the usual difficulties
257 associated with SIMD.
259 Also the `svshape` instruction only provides access to part of the
260 Matrix REMAP capability. Rotation and mirroring need to be done by
261 programming the SVSHAPE SPRs directly, which can take a lot more
264 ### FFT/DCT Triple Loop
266 DCT and FFT are some of the most astonishingly used algorithms in
267 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
268 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
271 An in-depth analysis showed that it is possible to do in-place in-register
272 DCT and FFT as long as twin-result "butterfly" instructions are provided.
273 These can be found in the [[openpower/isa/svfparith]] page if performing
274 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
275 integer operations would be required)*. These "butterfly" instructions
276 avoid the need for a temporary register because the two array positions
277 being overwritten will be "in-flight" in any In-Order or Out-of-Order
280 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
281 accept predicate masks. Given that it is common to perform recursive
282 convolutions combining smaller Power-2 DCT/FFT to create larger DCT/FFTs
283 in practice the RADIX2 limit is not a problem. A Bluestein convolution
284 to compute arbitrary length is demonstrated by
285 [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
289 The purpose of Indexing is to provide a generalised version of
290 Vector ISA "Permute" instructions, such as VSX `vperm`. The
291 Indexing is abstracted out and may be applied to much more
292 than an element move/copy, and is not limited for example
293 to the number of bytes that can fit into a VSX register.
294 Indexing may be applied to LD/ST (even on Indexed LD/ST
295 instructions such as `sv.lbzx`), arithmetic operations,
296 extsw: there is no artificial limit.
298 The only major caveat is that the registers to be used as
299 Indices must not be modified by any instruction after Indexed Mode
300 is established, and neither must MAXVL be altered. Additionally,
301 no register used as an Index may exceed MAXVL-1.
304 these conditions results in `UNDEFINED` behaviour.
305 These conditions allow a Read-After-Write (RAW) Hazard to be created on
306 the entire range of Indices to be subsequently used, but a corresponding
307 Write-After-Read Hazard by any instruction that modifies the Indices
308 **does not have to be created**. Given the large number of registers
309 involved in Indexing this is a huge resource saving and reduction
310 in micro-architectural complexity. MAXVL is likewise
311 included in the RAW Hazards because it is involved in calculating
312 how many registers are to be considered Indices.
314 With these Hazard Mitigations in place, high-performance implementations
315 may read-cache the Indices from the point where a given `svindex` instruction
316 is called (or SVSHAPE SPRs - and MAXVL- directly altered).
318 The original motivation for Indexed REMAP was to mitigate the need to add
319 an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
320 a stand-alone instruction. Usually a Vector ISA would add a non-conflicting
321 variant (as in VSX `vperm`) but it is common to need to permute by source,
322 with the risk of conflict, that has to be resolved, for example, in AVX-512
325 Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
326 destinations), which on a superficial analysis may be perceived to be a
327 problem, until it is recalled that, firstly, Simple-V is designed specifically
328 to require Program Order to be respected, and that Matrix, DCT and FFT
329 all *already* critically depend on overlapping Reads/Writes: Matrix
330 uses overlapping registers as accumulators. Thus the Register Hazard
331 Management needed by Indexed REMAP *has* to be in place anyway.
333 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
334 clearly that of the additional reading of the GPRs to be used as Indices,
335 plus the setup cost associated with creating those same Indices.
336 If any Deterministic REMAP can cover the required task, clearly it
337 is adviseable to use it instead.
339 *Programmer's note: some algorithms may require skipping of Indices exceeding
340 VL-1, not MAXVL-1. This may be achieved programmatically by performing
341 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
342 and RB contains the value of VL returned from `setvl`. The resultant
343 CR Fields may then be used as Predicate Masks to exclude those operations
344 with an Index exceeding VL-1.*
346 ### Parallel Reduction
348 Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
349 (Power ISA v3.0B) operation is leveraged, unmodified, to give the
350 *appearance* and *effect* of Reduction.
352 In Horizontal-First Mode, Vector-result reduction **requires**
353 the destination to be a Vector, which will be used to store
354 intermediary results.
356 Given that the tree-reduction schedule is deterministic,
357 Interrupts and exceptions
358 can therefore also be precise. The final result will be in the first
359 non-predicate-masked-out destination element, but due again to
360 the deterministic schedule programmers may find uses for the intermediate
363 When Rc=1 a corresponding Vector of co-resultant CRs is also
364 created. No special action is taken: the result and its CR Field
365 are stored "as usual" exactly as all other SVP64 Rc=1 operations.
367 Note that the Schedule only makes sense on top of certain instructions:
368 X-Form with a Register Profile of `RT,RA,RB` is fine because two sources
369 and the destination are all the same type. Like Scalar
370 Reduction, nothing is prohibited:
371 the results of execution on an unsuitable instruction may simply
372 not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
375 Critical to note regarding use of Parallel-Reduction REMAP is that,
376 exactly as with all REMAP Modes, the `svshape` instruction *requests*
377 a certain Vector Length (number of elements to reduce) and then
378 sets VL and MAXVL at the number of **operations** needed to be
379 carried out. Thus, equally as importantly, like Matrix REMAP
380 the total number of operations
381 is restricted to 127. Any Parallel-Reduction requiring more operations
382 will need to be done manually in batches (hierarchical
383 recursive Reduction).
385 Also important to note is that the Deterministic Schedule is arranged
386 so that some implementations *may* parallelise it (as long as doing so
387 respects Program Order and Register Hazards). Performance (speed)
389 implementation is neither strictly defined or guaranteed. As with
390 the Vulkan(tm) Specification, strict compliance is paramount whilst
391 performance is at the discretion of Implementors.
393 **Parallel-Reduction with Predication**
395 To avoid breaking the strict RISC-paradigm, keeping the Issue-Schedule
396 completely separate from the actual element-level (scalar) operations,
397 Move operations are **not** included in the Schedule. This means that
398 the Schedule leaves the final (scalar) result in the first-non-masked
399 element of the Vector used. With the predicate mask being dynamic
400 (but deterministic) this result could be anywhere.
402 If that result is needed to be moved to a (single) scalar register
403 then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
404 needed to get it, where the predicate is the exact same predicate used
405 in the prior Parallel-Reduction instruction.
407 * If there was only a single
408 bit in the predicate then the result will not have moved or been altered
409 from the source vector prior to the Reduction
410 * If there was more than one bit the result will be in the
411 first element with a predicate bit set.
413 In either case the result is in the element with the first bit set in
416 Programmer's Note: For *some* hardware implementations
417 the vector-to-scalar copy may be a slow operation, as may the Predicated
418 Parallel Reduction itself.
419 It may be better to perform a pre-copy
420 of the values, compressing them (VREDUCE-style) into a contiguous block,
421 which will guarantee that the result goes into the very first element
422 of the destination vector, in which case clearly no follow-up
423 vector-to-scalar MV operation is needed.
427 The simplest usage is to perform an overwrite, specifying all three
428 register operands the same.
431 svshape parallelreduce, 6
435 The Reduction Schedule will issue the Parallel Tree Reduction spanning
436 registers 8 through 13, by adjusting the offsets to RT, RA and RB as
437 necessary (see "Parallel Reduction algorithm" in a later section).
439 A non-overwrite is possible as well but just as with the overwrite
440 version, only those destination elements necessary for storing
441 intermediary computations will be written to: the remaining elements
442 will **not** be overwritten and will **not** be zero'd.
445 svshape parallelreduce, 6
449 However it is critical to note that if the source and destination are
450 not the same then the trick of using a follow-up vector-scalar MV will
453 ### Sub-Vector Horizontal Reduction
455 Note that when SVM is clear and SUBVL!=1 a Parallel Reduction is performed
456 on all first Subvector elements, followed by another separate independent
457 Parallel Reduction on all the second Subvector elements and so on.
459 for selectsubelement in (x,y,z,w):
460 parallelreduce(0..VL-1, selectsubelement)
462 By contrast, when SVM is set and SUBVL!=1, a Horizontal
463 Subvector mode is enabled, applying the Parallel Reduction
464 Algorithm to the Subvector Elements. The Parallel Reduction
465 is independently applied VL times, to each group of Subvector
466 elements. Bear in mind that predication is never applied down
467 into individual Subvector elements, but will be applied
468 to select whether the *entire* Parallel Reduction on each
469 group is performed or not.
471 Â for (i = 0; i < VL; i++)
472 if (predval & 1<<i) # predication
474 parallelreduction([el.x, el.y, el.z, el.w])
476 Note that as this is a Parallel Reduction, for best results
477 it should be an overwrite operation, where the result for
478 the Horizontal Reduction of each Subvector will be in the
479 first Subvector element.
480 Also note that use of Rc=1 is `UNDEFINED` behaviour.
482 In essence what is happening here is that Structure Packing is being
483 combined with Parallel Reduction. If the Subvector elements may be
484 laid out as a 2D matrix, with the Subvector elements on rows,
485 and Parallel Reduction is applied per row, then if `SVM` is **clear**
486 the Matrix is transposed (like Pack/Unpack)
487 before still applying the Parallel Reduction to the **row**.
489 ## Determining Register Hazards
491 For high-performance (Multi-Issue, Out-of-Order) systems it is critical
492 to be able to statically determine the extent of Vectors in order to
493 allocate pre-emptive Hazard protection. The next task is to eliminate
494 masked-out elements using predicate bits, freeing up the associated
497 For non-REMAP situations `VL` is sufficient to ascertain early
498 Hazard coverage, and with SVSTATE being a high priority cached
499 quantity at the same level of MSR and PC this is not a problem.
501 The problems come when REMAP is enabled. Indexed REMAP must instead
502 use `MAXVL` as the earliest (simplest)
503 batch-level Hazard Reservation indicator,
504 but Matrix, FFT and Parallel Reduction must all use completely different
505 schemes. The reason is that VL is used to step through the total
506 number of *operations*, not the number of registers. The "Saving Grace"
507 is that all of the REMAP Schedules are Deterministic.
509 Advance-notice Parallel computation and subsequent cacheing
510 of all of these complex Deterministic REMAP Schedules is
511 *strongly recommended*, thus allowing clear and precise multi-issue
512 batched Hazard coverage to be deployed, *even for Indexed Mode*.
513 This is only possible for Indexed due to the strict guidelines
514 given to Programmers.
516 In short, there exists solutions to the problem of Hazard Management,
517 with varying degrees of refinement possible at correspondingly
518 increasing levels of complexity in hardware.
520 ## REMAP area of SVSTATE
522 The following bits of the SVSTATE SPR are used for REMAP:
524 |32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
525 | -- | -- | -- | -- | -- | ----- | ------ |
526 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
528 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
529 mi0-2 apply to RA, RB, RC respectively, as input registers, and
530 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
531 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
532 SVSHAPE is actively applied or not.
534 * bit 0 of SVme indicates if mi0 is applied to RA / FRA
535 * bit 1 of SVme indicates if mi1 is applied to RB / FRB
536 * bit 2 of SVme indicates if mi2 is applied to RC / FRC
537 * bit 3 of SVme indicates if mo0 is applied to RT / FRT
538 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
539 (LD/ST-with-update has an implicit 2nd write register, RA)
541 # svremap instruction <a name="svremap"> </a>
545 svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
547 |0 |6 |11 |13 |15 |17 |19 |21 | 22.25 |26..31 |
548 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
549 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
553 * svremap SVme,mi0,mi1,mi2,mo0,mo1,pst
557 # registers RA RB RC RT EA/FRS SVSHAPE0-3 indices
558 SVSTATE[32:33] <- mi0
559 SVSTATE[34:35] <- mi1
560 SVSTATE[36:37] <- mi2
561 SVSTATE[38:39] <- mo0
562 SVSTATE[40:41] <- mo1
563 # enable bit for RA RB RC RT EA/FRS
564 SVSTATE[42:46] <- SVme
565 # persistence bit (applies to more than one instruction)
568 Special Registers Altered:
572 `svremap` determines the relationship between registers and SVSHAPE SPRs.
573 The bitmask `SVme` determines which registers have a REMAP applied, and mi0-mo1
574 determine which shape is applied to an activated register. the `pst` bit if
575 cleared indicated that the REMAP operation shall only apply to the immediately-following
576 instruction. If set then REMAP remains permanently enabled until such time as it is
577 explicitly disabled, either by `setvl` setting a new MAXVL, or with another
578 `svremap` instruction. `svindex` and `svshape2` are also capable of setting or
579 clearing persistence, as well as partially covering a subset of the capability of
580 `svremap` to set register-to-SVSHAPE relationships.
582 # SHAPE Remapping SPRs
584 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
585 which have the same format.
587 Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
588 disabled: the register's elements are a linear (1D) vector.
590 |31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
591 |---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
592 |0b00 |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
593 |0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
594 |0b01 |submode|offset| invxyz | submode2| zdimsz |mode |xdimsz|DCT/FFT|
595 |0b10 |submode|offset| invxyz | rsvd | rsvd |rsvd |xdimsz|Preduce|
596 |0b11 | | | | | | | |rsvd |
598 mode sets different behaviours (straight matrix multiply, FFT, DCT).
600 * **mode=0b00** sets straight Matrix Mode
601 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
602 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
603 * **mode=0b10** sets "Parallel Reduction" Schedules.
605 ## Parallel Reduction Mode
607 Creates the Schedules for Parallel Tree Reduction.
609 * **submode=0b00** selects the left operand index
610 * **submode=0b01** selects the right operand index
612 * When bit 0 of `invxyz` is set, the order of the indices
613 in the inner for-loop are reversed. This has the side-effect
614 of placing the final reduced result in the last-predicated element.
615 It also has the indirect side-effect of swapping the source
616 registers: Left-operand index numbers will always exceed
617 Right-operand indices.
618 When clear, the reduced result will be in the first-predicated
619 element, and Left-operand indices will always be *less* than
621 * When bit 1 of `invxyz` is set, the order of the outer loop
622 step is inverted: stepping begins at the nearest power-of two
623 to half of the vector length and reduces by half each time.
624 When clear the step will begin at 2 and double on each
629 submode2=0 is for FFT. For FFT submode the following schedules may be
632 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
634 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
636 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
638 When submode2 is 1 or 2, for DCT inner butterfly submode the following
639 schedules may be selected. When submode2 is 1, additional bit-reversing
642 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
644 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
645 in reverse-order, in-place
646 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
647 useful for calculating the cosine coefficient
648 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
649 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
651 When submode2 is 3 or 4, for DCT outer butterfly submode the following
652 schedules may be selected. When submode is 3, additional bit-reversing
655 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
656 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
658 `zdimsz` is used as an in-place "Stride", particularly useful for
659 column-based in-place DCT/FFT.
663 In Matrix Mode, skip allows dimensions to be skipped from being included
664 in the resultant output index. this allows sequences to be repeated:
665 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
666 modulo ```0 1 2 0 1 2 ...```
668 * **skip=0b00** indicates no dimensions to be skipped
669 * **skip=0b01** sets "skip 1st dimension"
670 * **skip=0b10** sets "skip 2nd dimension"
671 * **skip=0b11** sets "skip 3rd dimension"
673 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
674 zero then x-dimensional counting begins from 0 and increments, otherwise
675 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
677 offset will have the effect of offsetting the result by ```offset``` elements:
680 GPR(RT + remap(i) + SVSHAPE.offset) = ....
682 this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
683 bear in mind that unlike a static compiler SVSHAPE.offset may
684 be set dynamically at runtime.
686 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
687 that the array dimensionality for that dimension is 1. any dimension
688 not intended to be used must have its value set to 0 (dimensionality
689 of 1). A value of xdimsz=2 would indicate that in the first dimension
690 there are 3 elements in the array. For example, to create a 2D array
691 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
693 The format of the array is therefore as follows:
695 array[xdimsz+1][ydimsz+1][zdimsz+1]
697 However whilst illustrative of the dimensionality, that does not take the
698 "permute" setting into account. "permute" may be any one of six values
699 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
700 below shows how the permutation dimensionality order works:
702 | permute | order | array format |
703 | ------- | ----- | ------------------------ |
704 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
705 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
706 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
707 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
708 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
709 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
710 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
711 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
713 In other words, the "permute" option changes the order in which
714 nested for-loops over the array would be done. See executable
715 python reference code for further details.
717 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
720 With all these options it is possible to support in-place transpose,
721 in-place rotate, Matrix Multiply and Convolutions, without being
722 limited to Power-of-Two dimension sizes.
726 Indexed Mode activates reading of the element indices from the GPR
727 and includes optional limited 2D reordering.
728 In its simplest form (without elwidth overrides or other modes):
732 return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
735 element_result = ....
736 GPR(RT + indexed_remap(i)) = element_result
739 With element-width overrides included, and using the pseudocode
740 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
745 svreg = SVSHAPE.SVGPR << 1
746 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
747 offs = SVSHAPE.offset
748 return get_polymorphed_reg(svreg, srcwid, i) + offs
751 element_result = ....
752 rt_idx = indexed_remap(i)
753 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
756 Matrix-style reordering still applies to the indices, except limited
757 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
758 (Y,X) for in-place Transposition.
759 Only one dimension may optionally be skipped. Inversion of either
760 X or Y or both is possible (2D mirroring). Pseudocode for Indexed Mode (including elwidth
761 overrides) may be written in terms of Matrix Mode, specifically
762 purposed to ensure that the 3rd dimension (Z) has no effect:
765 def index_remap(ISHAPE, i):
766 MSHAPE.skip = 0b0 || ISHAPE.sk1
767 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
768 MSHAPE.xdimsz = ISHAPE.xdimsz
769 MSHAPE.ydimsz = ISHAPE.ydimsz
770 MSHAPE.zdimsz = 0 # disabled
771 if ISHAPE.permute = 0b110 # 0,1
772 MSHAPE.permute = 0b000 # 0,1,2
773 if ISHAPE.permute = 0b111 # 1,0
774 MSHAPE.permute = 0b010 # 1,0,2
775 el_idx = remap_matrix(MSHAPE, i)
776 svreg = ISHAPE.SVGPR << 1
777 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
779 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
782 The most important observation above is that the Matrix-style
783 remapping occurs first and the Index lookup second. Thus it
784 becomes possible to perform in-place Transpose of Indices which
785 may have been costly to set up or costly to duplicate
786 (waste register file space).
788 # svshape instruction <a name="svshape"> </a>
790 Form: SVM-Form SV "Matrix" Form (see [[isatables/fields.text]])
792 svshape SVxd,SVyd,SVzd,SVRM,vf
794 | 0.5|6.10 |11.15 |16..20 | 21..24 | 25 | 26..31| name |
795 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
796 |OPCD| SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
799 # for convenience, VL to be calculated and stored in SVSTATE
801 mscale[0:5] <- 0b000001 # for scaling MAXVL
802 itercount[0:6] <- [0] * 7
803 SVSTATE[0:31] <- [0] * 32
804 # only overwrite REMAP if "persistence" is zero
805 if (SVSTATE[62] = 0b0) then
806 SVSTATE[32:33] <- 0b00
807 SVSTATE[34:35] <- 0b00
808 SVSTATE[36:37] <- 0b00
809 SVSTATE[38:39] <- 0b00
810 SVSTATE[40:41] <- 0b00
811 SVSTATE[42:46] <- 0b00000
814 # clear out all SVSHAPEs
815 SVSHAPE0[0:31] <- [0] * 32
816 SVSHAPE1[0:31] <- [0] * 32
817 SVSHAPE2[0:31] <- [0] * 32
818 SVSHAPE3[0:31] <- [0] * 32
820 # set schedule up for multiply
821 if (SVrm = 0b0000) then
822 # VL in Matrix Multiply is xd*yd*zd
823 xd <- (0b00 || SVxd) + 1
824 yd <- (0b00 || SVyd) + 1
825 zd <- (0b00 || SVzd) + 1
827 vlen[0:6] <- n[14:20]
828 # set up template in SVSHAPE0, then copy to 1-3
829 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
830 SVSHAPE0[6:11] <- (0b0 || SVyd) # ydim
831 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim
832 SVSHAPE0[28:29] <- 0b11 # skip z
834 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
835 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
836 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
838 SVSHAPE1[18:20] <- 0b001 # permute x,z,y
839 SVSHAPE1[28:29] <- 0b01 # skip z
841 SVSHAPE2[18:20] <- 0b001 # permute x,z,y
842 SVSHAPE2[28:29] <- 0b11 # skip y
844 # set schedule up for FFT butterfly
845 if (SVrm = 0b0001) then
846 # calculate O(N log2 N)
849 if SVxd[4-n] = 0 then
852 n <- ((0b0 || SVxd) + 1) * n
854 # set up template in SVSHAPE0, then copy to 1-3
856 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
857 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D FFT)
858 mscale <- (0b0 || SVzd) + 1
859 SVSHAPE0[30:31] <- 0b01 # Butterfly mode
861 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
862 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
864 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
866 SVSHAPE2[28:29] <- 0b10 # k schedule
868 # set schedule up for (i)DCT Inner butterfly
869 # SVrm Mode 2 (Mode 6 for iDCT) is for pre-calculated coefficients,
870 # SVrm Mode 4 (Mode 12 for iDCT) is for on-the-fly (Vertical-First Mode)
871 if ((SVrm = 0b0010) | (SVrm = 0b0100) |
872 (SVrm = 0b1010) | (SVrm = 0b1100)) then
873 # calculate O(N log2 N)
876 if SVxd[4-n] = 0 then
879 n <- ((0b0 || SVxd) + 1) * n
881 # set up template in SVSHAPE0, then copy to 1-3
883 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
884 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
885 mscale <- (0b0 || SVzd) + 1
886 if (SVrm = 0b1011) then
887 SVSHAPE0[30:31] <- 0b11 # iDCT mode
888 SVSHAPE0[18:20] <- 0b011 # iDCT Outer Butterfly sub-mode
889 SVSHAPE0[21:23] <- 0b101 # "inverse" on outer and inner loop
891 SVSHAPE0[30:31] <- 0b01 # DCT mode
892 SVSHAPE0[18:20] <- 0b100 # DCT Outer Butterfly sub-mode
893 SVSHAPE0[6:11] <- 0b000010 # DCT Butterfly mode
895 SVSHAPE1[0:31] <- SVSHAPE0[0:31] # j+halfstep schedule
896 SVSHAPE2[0:31] <- SVSHAPE0[0:31] # costable coefficients
898 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
899 # reset costable "striding" to 1
900 SVSHAPE2[12:17] <- 0b000000
902 # set schedule up for DCT COS table generation
903 if (SVrm = 0b0101) | (SVrm = 0b1101) then
904 # calculate O(N log2 N)
906 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
907 itercount[0:6] <- (0b0 || itercount[0:5])
910 if SVxd[4-n] = 0 then
913 vlen[0:6] <- vlen + itercount
914 itercount[0:6] <- (0b0 || itercount[0:5])
915 # set up template in SVSHAPE0, then copy to 1-3
917 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
918 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
919 mscale <- (0b0 || SVzd) + 1
920 SVSHAPE0[30:31] <- 0b01 # DCT/FFT mode
921 SVSHAPE0[6:11] <- 0b000100 # DCT Inner Butterfly COS-gen mode
922 if (SVrm = 0b0101) then
923 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop for DCT
925 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
926 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
927 # for cos coefficient
928 SVSHAPE1[28:29] <- 0b10 # ci schedule
929 SVSHAPE2[28:29] <- 0b11 # size schedule
931 # set schedule up for iDCT / DCT inverse of half-swapped ordering
932 if (SVrm = 0b0110) | (SVrm = 0b1110) | (SVrm = 0b1111) then
933 vlen[0:6] <- (0b00 || SVxd) + 0b0000001
934 # set up template in SVSHAPE0
935 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
936 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
937 mscale <- (0b0 || SVzd) + 1
938 if (SVrm = 0b1110) then
939 SVSHAPE0[18:20] <- 0b001 # DCT opposite half-swap
940 if (SVrm = 0b1111) then
941 SVSHAPE0[30:31] <- 0b01 # FFT mode
943 SVSHAPE0[30:31] <- 0b11 # DCT mode
944 SVSHAPE0[6:11] <- 0b000101 # DCT "half-swap" mode
946 # set schedule up for parallel reduction
947 if (SVrm = 0b0111) then
948 # calculate the total number of operations (brute-force)
950 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
951 step[0:6] <- 0b0000001
953 do while step <u itercount
954 newstep <- step[1:6] || 0b0
956 do while (j+step <u itercount)
960 # VL in Parallel-Reduce is the number of operations
962 # set up template in SVSHAPE0, then copy to 1. only 2 needed
963 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
964 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
965 mscale <- (0b0 || SVzd) + 1
966 SVSHAPE0[30:31] <- 0b10 # parallel reduce submode
968 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
969 # set up right operand (left operand 28:29 is zero)
970 SVSHAPE1[28:29] <- 0b01 # right operand
972 # set VL, MVL and Vertical-First
973 m[0:12] <- vlen * mscale
974 maxvl[0:6] <- m[6:12]
975 SVSTATE[0:6] <- maxvl # MAVXL
976 SVSTATE[7:13] <- vlen # VL
980 Special Registers Altered:
984 `svshape` is a convenience instruction that reduces instruction
985 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
986 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
987 including VL and MAXVL. Using `svshape` therefore does not also
992 * **SVxd** - SV REMAP "xdim"
993 * **SVyd** - SV REMAP "ydim"
994 * **SVzd** - SV REMAP "zdim"
995 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
996 * **vf** - sets "Vertical-First" mode
998 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
999 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
1001 There are 14 REMAP Modes (2 bits are RESERVED for `svshape2`)
1003 | SVRM | Remap Mode description |
1005 | 0b0000 | Matrix 1/2/3D |
1006 | 0b0001 | FFT Butterfly |
1007 | 0b0010 | DCT Inner butterfly, pre-calculated coefficients |
1008 | 0b0011 | DCT Outer butterfly |
1009 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1010 | 0b0101 | DCT COS table index generation |
1011 | 0b0110 | DCT half-swap |
1012 | 0b0111 | Parallel Reduction |
1013 | 0b1000 | reserved for svshape2 |
1014 | 0b1001 | reserved for svshape2 |
1015 | 0b1010 | iDCT Inner butterfly, pre-calculated coefficients |
1016 | 0b1011 | iDCT Outer butterfly |
1017 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1018 | 0b1101 | iDCT COS table index generation |
1019 | 0b1110 | iDCT half-swap |
1020 | 0b1111 | FFT half-swap |
1022 Examples showing how all of these Modes operate exists in the online
1023 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD). Explaining
1024 these Modes further in detail is beyond the scope of this document.
1026 In Indexed Mode, there are only 5 bits available to specify the GPR
1027 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
1028 5 bits are given in the `SVxd` field: the bottom two implicit bits
1029 will be zero (`SVxd || 0b00`).
1031 `svshape` has *limited applicability* due to being a 32-bit instruction.
1032 The full capability of SVSHAPE SPRs may be accessed by directly writing
1033 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
1034 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
1035 instruction, `psvshape`, may extend the capability here.
1037 # svindex instruction <a name="svindex"> </a>
1040 | 0.5|6.10 |11.15 |16.20 | 21..25 | 26..31| name | Form |
1041 | -- | -- | --- | ---- | ----------- | ------| -------- | ---- |
1042 |OPCD| SVG | rmm | SVd | ew/yx/mm/sk | XO | svindex | SVI-Form |
1046 * svindex SVG,rmm,SVd,ew,SVyx,mm,sk
1050 # based on nearest MAXVL compute other dimension
1054 do while d*dim <u ([0]*4 || MVL)
1057 # set up template, then copy once location identified
1059 shape[30:31] <- 0b00 # mode
1061 shape[18:20] <- 0b110 # indexed xd/yd
1062 shape[0:5] <- (0b0 || SVd) # xdim
1063 if sk = 0 then shape[6:11] <- 0 # ydim
1064 else shape[6:11] <- 0b111111 # ydim max
1066 shape[18:20] <- 0b111 # indexed yd/xd
1067 if sk = 1 then shape[6:11] <- 0 # ydim
1068 else shape[6:11] <- d-1 # ydim max
1069 shape[0:5] <- (0b0 || SVd) # ydim
1070 shape[12:17] <- (0b0 || SVG) # SVGPR
1071 shape[28:29] <- ew # element-width override
1072 shape[21] <- sk # skip 1st dimension
1074 # select the mode for updating SVSHAPEs
1075 SVSTATE[62] <- mm # set or clear persistence
1077 # clear out all SVSHAPEs first
1078 SVSHAPE0[0:31] <- [0] * 32
1079 SVSHAPE1[0:31] <- [0] * 32
1080 SVSHAPE2[0:31] <- [0] * 32
1081 SVSHAPE3[0:31] <- [0] * 32
1082 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1083 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1087 # activate requested shape
1088 if idx = 0 then SVSHAPE0 <- shape
1089 if idx = 1 then SVSHAPE1 <- shape
1090 if idx = 2 then SVSHAPE2 <- shape
1091 if idx = 3 then SVSHAPE3 <- shape
1092 SVSTATE[bit*2+32:bit*2+33] <- idx
1093 # increment shape index, modulo 4
1094 if idx = 3 then idx <- 0
1097 # refined SVSHAPE/REMAP update mode
1100 if idx = 0 then SVSHAPE0 <- shape
1101 if idx = 1 then SVSHAPE1 <- shape
1102 if idx = 2 then SVSHAPE2 <- shape
1103 if idx = 3 then SVSHAPE3 <- shape
1104 SVSTATE[bit*2+32:bit*2+33] <- idx
1105 SVSTATE[46-bit] <- 1
1107 Special Registers Altered:
1111 `svindex` is a convenience instruction that reduces instruction
1112 count for Indexed REMAP Mode. It sets up
1113 (overwrites) all required SVSHAPE SPRs and can modify the REMAP
1114 area of the SVSTATE SPR as well. The relevant SPRs *may* be directly programmed with
1115 `mtspr` however it is laborious to do so: svindex saves instructions
1116 covering much of Indexed REMAP capability.
1120 * **SVd** - SV REMAP x/y dim
1121 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
1123 * **ew** - sets element width override on the Indices
1124 * **SVG** - GPR SVG<<2 to be used for Indexing
1125 * **yx** - 2D reordering to be used if yx=1
1126 * **mm** - mask mode. determines how `rmm` is interpreted.
1127 * **sk** - Dimension skipping enabled
1129 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
1130 "off-by-one". In the assembler
1131 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
1133 *Note: when `yx=1,sk=0` the second dimension is calculated as
1138 * `rmm`, like REMAP.SVme, has bit 0
1139 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
1140 bit 3 to mo0 and bit 4 to mi1
1141 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
1142 * for each bit set in the 5-bit `rmm`, in order, the first
1143 as-yet-unset SVSHAPE will be updated
1144 with the other operands in the instruction, and the REMAP
1146 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
1147 * SVSTATE persistence bit is cleared
1148 * No other alterations to SVSTATE are carried out
1150 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
1151 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
1152 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
1153 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
1155 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
1156 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
1157 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
1159 Rough algorithmic form:
1161 marray = [mi0, mi1, mi2, mo0, mo1]
1164 if not rmm[bit]: continue
1166 SVSTATE{marray[bit]} = idx
1167 idx = (idx+1) modulo 4
1171 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
1172 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
1174 * only the selected SVSHAPE is overwritten
1175 * only the relevant bits in the REMAP area of SVSTATE are updated
1176 * REMAP persistence bit is set.
1178 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
1179 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
1180 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
1181 set to 2 (SVSHAPE2).
1183 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
1184 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
1185 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
1186 set to 3 (SVSHAPE3).
1188 Rough algorithmic form:
1190 marray = [mi0, mi1, mi2, mo0, mo1]
1194 SVSTATE{marray[bit]} = idx
1197 In essence, `mm=0` is intended for use to set as much of the
1198 REMAP State SPRs as practical with a single instruction,
1199 whilst `mm=1` is intended to be a little more refined.
1201 **Usage guidelines**
1203 * **Disable 2D mapping**: to only perform Indexing without
1204 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
1206 * **Modulo 1D mapping**: to perform Indexing cycling through the
1207 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
1208 no requirement to set VL equal to a multiple of N.
1209 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
1210 `xdim=M,ydim=CEIL(MAXVL/M)`.
1212 Beyond these mappings it becomes necessary to write directly to
1213 the SVSTATE SPRs manually.
1215 # svshape2 (offset) <a name="svshape2"> </a>
1217 `svshape2` is an additional convenience instruction that prioritises
1218 setting `SVSHAPE.offset`. Its primary purpose is for use when
1219 element-width overrides are used. It has identical capabilities to `svindex` and
1220 in terms of both options (skip, etc.) and ability to activate REMAP
1221 (rmm, mask mode) but unlike `svindex` it does not set GPR REMAP,
1222 only a 1D or 2D `svshape`, and
1223 unlike `svshape` it can set an arbirrary `SVSHAPE.offset` immediate.
1225 One of the limitations of Simple-V is that Vector elements start on the boundary
1226 of the Scalar regfile, which is fine when element-width overrides are not
1227 needed. If the starting point of a Vector with smaller elwidths must begin
1228 in the middle of a register, normally there would be no way to do so except
1229 through LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`is
1232 svshape2 offs,yx,rmm,SVd,sk,mm
1234 | 0.5|6..9|10|11.15 |16..20 | 21..25 | 25 | 26..31| name |
1235 | -- |----|--| --- | ----- | ------ | -- | ------| -------- |
1236 |OPCD|offs|yx| rmm | SVd | 100/mm | sk | XO | svshape |
1238 * **offs** (4 bits) - unsigned offset
1239 * **yx** (1 bit) - swap XY to YX
1240 * **SVd** dimension size
1241 * **rmm** REMAP mask
1243 * **sk** (1 bit) skips 1st dimension if set
1245 Dimensions are calculated exactly as `svindex`. `rmm` and
1246 `mm` are as per `svindex`.
1248 *Programmer's Note: offsets for `svshape2` may be specified in the range
1249 0-15. Given that the principle of Simple-V is to fit on top of
1250 byte-addressable register files and that GPR and FPR are 64-bit (8 bytes)
1251 it should be clear that the offset may, when `elwidth=8`, begin an
1252 element-level operation starting element zero at any arbitrary byte.
1253 On cursory examination attempting to go beyond the range 0-7 seems
1254 unnecessary given that the **next GPR or FPR** is an
1255 alias for an offset in the range 8-15. Thus by simply increasing
1256 the starting Vector point of the operation to the next register it
1257 can be seen that the offset of 0-7 would be sufficient. Unfortunately
1258 however some operations are EXTRA2-encoded it is **not possible**
1259 to increase the GPR/FPR register number by one, because EXTRA2-encoding
1260 of GPR/FPR Vector numbers are restricted to even numbering.
1261 For CR Fields the EXTRA2 encoding is even more sparse.
1262 The additional offset range (8-15) helps overcome these limitations.*
1264 *Hardware Implementor's note: with the offsets only being immediates
1265 and with register numbering being entirely immediate as well it is
1266 possible to correctly compute Register Hazards without requiring
1267 reading the contents of any SPRs. If however there are
1268 instructions that have directly written to the SVSTATE or SVSHAPE
1269 SPRs and those instructions are still in-flight then this position
1270 is clearly **invalid**.*
1278 # svstep: Vertical-First Stepping and status reporting
1282 * svstep RT,SVi,vf (Rc=0)
1283 * svstep. RT,SVi,vf (Rc=1)
1285 | 0-5|6-10|11.15|16..22| 23-25 | 26-30 |31| Form |
1286 |----|----|-----|------|----------|-------|--|--------- |
1287 |PO | RT | / | SVi | / / vf | XO |Rc| SVL-Form |
1292 if SVi[3:4] = 0b11 then
1293 # store pack and unpack in SVSTATE
1294 SVSTATE[53] <- SVi[5]
1295 SVSTATE[54] <- SVi[6]
1296 RT <- [0]*62 || SVSTATE[53:54]
1298 # Vertical-First explicit stepping.
1299 step <- SVSTATE_NEXT(SVi, vf)
1300 RT <- [0]*57 || step
1303 Special Registers Altered:
1321 Add the following to Book I, 1.6.1, SVI-Form
1324 |0 |6 |11 |16 |21 |23 |24|25|26 31|
1325 | PO | SVG|rmm | SVd |ew |SVyx|mm|sk| XO |
1328 Add the following to Book I, 1.6.1, SVM-Form
1331 |0 |6 |11 |16 |21 |25 |26 |31 |
1332 | PO | SVxd | SVyd | SVzd | SVrm |vf | XO |
1335 Add the following to Book I, 1.6.1, SVM2-Form
1338 # 1.6.35.1 SVM2-FORM
1339 |0 |6 |10 |11 |16 |21 |24|25 |26 |31 |
1340 | PO | SVo |SVyx| rmm | SVd |XO |mm|sk | XO |
1343 Add the following to Book I, 1.6.1, SVRM-Form
1347 |0 |6 |11 |13 |15 |17 |19 |21 |22 |26 |31 |
1348 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 |pst |/// | XO |
1351 * Add `SVI, SVM, SVM2, SVRM` to `XO (26:31)` Field in Book I, 1.6.2
1353 Add the following to Book I, 1.6.2
1357 Field used in REMAP to select the SVSHAPE for 1st input register
1360 Field used in REMAP to select the SVSHAPE for 2nd input register
1363 Field used in REMAP to select the SVSHAPE for 3rd input register
1366 Field used to specify the meaning of the rmm field for SVI-Form
1370 Field used in REMAP to select the SVSHAPE for 1st output register
1373 Field used in REMAP to select the SVSHAPE for 2nd output register
1376 Field used in REMAP to indicate "persistence" mode (REMAP
1377 continues to apply to multiple instructions)
1380 REMAP Mode field for SVI-Form and SVM2-Form
1383 Field used to specify dimensional skipping in svindex
1386 Immediate field used to specify the size of the REMAP dimension
1387 in the svindex and svshape2 instructions
1390 Immediate field used to specify a 9-bit signed
1391 two's complement integer which is concatenated
1392 on the right with 0b00 and sign-extended to 64 bits.
1395 Field used to specify a GPR to be used as a
1396 source for indexing.
1399 Simple-V immediate field for setting VL or MVL
1402 Simple-V "REMAP" map-enable bits (0-4)
1405 Field used by the svshape2 instruction as an offset
1408 Simple-V "REMAP" Mode
1411 Simple-V "REMAP" x-dimension size
1414 Simple-V "REMAP" y-dimension size
1417 Simple-V "REMAP" z-dimension size
1423 Appendix E Power ISA sorted by opcode
1424 Appendix F Power ISA sorted by version
1425 Appendix G Power ISA sorted by Compliancy Subset
1426 Appendix H Power ISA sorted by mnemonic
1428 | Form | Book | Page | Version | mnemonic | Description |
1429 |------|------|------|---------|----------|-------------|
1430 | SVRM | I | # | 3.0B | svremap | REMAP enabling instruction |