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
88 # REMAP <a name="remap" />
90 REMAP is an advanced form of Vector "Structure Packing" that
91 provides hardware-level support for commonly-used *nested* loop patterns
92 that would otherwise require full inline loop unrolling.
93 For more general reordering an Indexed REMAP mode is available
94 (an abstracted analog to `xxperm`).
96 REMAP allows the usual sequential vector loop `0..VL-1` to be "reshaped" (re-mapped)
97 from a linear form to a 2D or 3D transposed form, or "offset" to permit
98 arbitrary access to elements (when elwidth overrides are used),
99 independently on each Vector src or dest
100 register. Aside from Indexed REMAP this is entirely Hardware-accelerated
101 reordering and consequently not costly in terms of register access. It
102 will however place a burden on Multi-Issue systems but no more than if
103 the equivalent Scalar instructions were explicitly
104 loop-unrolled without SVP64, and some advanced implementations may even find
105 the Deterministic nature of the Scheduling to be easier on resources.
107 The initial primary motivation of REMAP was for Matrix Multiplication, reordering
108 of sequential data in-place: in-place DCT and FFT were easily justified given the
109 exceptionally 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 hardware-controlled 100% Deterministic loop to
113 perform 5x3 times 3x4 Matrix multiplication,
114 generating 60 FMACs *without needing explicit assembler unrolling*.
115 Additional uses include regular "Structure Packing"
116 such as RGB pixel data extraction and reforming.
118 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
119 Vector ISAs which would typically only have a limited set of instructions
120 that can be structure-packed (LD/ST typically), REMAP may be applied to
121 literally any instruction: CRs, Arithmetic, Logical, LD/ST, anything.
123 Note that REMAP does not *directly* apply to sub-vector elements but
124 only to the group: that
125 is what swizzle is for. Swizzle *can* however be applied to the same
126 instruction as REMAP. As explained in [[sv/mv.swizzle]]
127 and the [[svp64/appendix]], Pack and Unpack EXTRA Mode bits
128 can extend down into Sub-vector elements to perform vec2/vec3/vec4
129 sequential reordering, but even here, REMAP is not *individually*
130 extended down to the actual sub-vector elements themselves.
132 In its general form, REMAP is quite expensive to set up, and on some
133 implementations may introduce
134 latency, so should realistically be used only where it is worthwhile.
135 Given that even with latency the fact that up to 127 operations
136 can be requested to be issued (from a single instruction) it should
137 be clear that REMAP should not be dismissed for *possible* latency alone.
138 Commonly-used patterns such as Matrix Multiply, DCT and FFT have
139 helper instruction options which make REMAP easier to use.
141 There are four types of REMAP:
143 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
144 Matrix transpose and rotate. The Shapes are set up for an "Outer Product"
146 * **FFT/DCT**, with full triple-loop in-place support: limited to
148 * **Indexing**, for any general-purpose reordering, also includes
149 limited 2D reshaping.
150 * **Parallel Reduction**, for scheduling a sequence of operations
151 in a Deterministic fashion, in a way that may be parallelised,
152 to reduce a Vector down to a single value.
154 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
155 REMAP Schedules are 100% Deterministic **including Indexing** and are
156 designed to be incorporated in between the Decode and Issue phases,
157 directly into Register Hazard Management.
159 Parallel Reduction is unusual in that it requires a full vector array
160 of results (not a scalar) and uses the rest of the result Vector for
161 the purposes of storing intermediary calculations. As these intermediary
162 results are Deterministically computed they may be useful.
163 Additionally, because the intermediate results are always written out
164 it is possible to service Precise Interrupts without affecting latency
165 (a common limitation of Vector ISAs implementing explicit
166 Parallel Reduction instructions).
170 * normal vector element read/write of operands would be sequential
172 * this is not appropriate for (e.g.) Matrix multiply which requires
173 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
174 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
175 with this. both are expensive (copy large vectors, spill through memory)
176 and very few Packed SIMD ISAs cope with non-Power-2.
177 * REMAP **redefines** the order of access according to set
178 (Deterministic) "Schedules".
179 * The Schedules are not at all restricted to power-of-two boundaries
180 making it unnecessary to have for example specialised 3x4 transpose
181 instructions of other Vector ISAs.
183 Only the most commonly-used algorithms in computer science have REMAP
184 support, due to the high cost in both the ISA and in hardware. For
185 arbitrary remapping the `Indexed` REMAP may be used.
189 * `svshape` to set the type of reordering to be applied to an
190 otherwise usual `0..VL-1` hardware for-loop
191 * `svremap` to set which registers a given reordering is to apply to
193 * `sv.{instruction}` where any Vectorised register marked by `svremap`
194 will have its ordering REMAPPED according to the schedule set
197 The following illustrative example multiplies a 3x4 and a 5x3
202 svshape 5, 4, 3, 0, 0
203 svremap 15, 1, 2, 3, 0, 0, 0, 0
204 sv.fmadds *0, *8, *16, *0
207 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
208 * svremap activates four out of five registers RA RB RC RT RS (15)
214 - RS Remapping to not be activated
215 * sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
216 * With REMAP being active each register's element index is
217 *independently* transformed using the specified SHAPEs.
219 Thus the Vector Loop is arranged such that the use of
220 the multiply-and-accumulate instruction executes precisely the required
221 Schedule to perform an in-place in-registers Matrix Multiply with no
222 need to perform additional Transpose or register copy instructions.
223 The example above may be executed as a unit test and demo,
224 [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)
228 This section summarises the motivation for each REMAP Schedule
229 and briefly goes over their characteristics and limitations.
230 Further details on the Deterministic Precise-Interruptible algorithms
231 used in these Schedules is found in the [[sv/remap/appendix]].
233 ### Matrix (1D/2D/3D shaping)
235 Matrix Multiplication is a huge part of High-Performance Compute,
237 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
238 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
239 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
240 Aside from the cost of the load on the L1 I-Cache, the trick only
241 works if one of the dimensions X or Y are power-two. Prime Numbers
242 (5x7, 3x5) become deeply problematic to unroll.
244 Even traditional Scalable Vector ISAs have issues with Matrices, often
245 having to perform data Transpose by pushing out through Memory and back,
246 or computing Transposition Indices (costly) then copying to another
249 Matrix REMAP was thus designed to solve these issues by providing Hardware
251 "Schedules" that can view what would otherwise be limited to a strictly
252 linear Vector as instead being 2D (even 3D) *in-place* reordered.
253 With both Transposition and non-power-two being supported the issues
254 faced by other ISAs are mitigated.
256 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
257 restricted to 127: up to 127 FMAs (or other operation)
258 may be performed in total.
259 Also given that it is in-registers only at present some care has to be
260 taken on regfile resource utilisation. However it is perfectly possible
261 to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
262 the usual 6-level large Matrix Multiply, without the usual difficulties
263 associated with SIMD.
265 Also the `svshape` instruction only provides access to part of the
266 Matrix REMAP capability. Rotation and mirroring need to be done by
267 programming the SVSHAPE SPRs directly, which can take a lot more
268 instructions. Future versions of SVP64 will include EXT1xx prefixed
269 variants (`psvshape`) which provide more comprehensive capacity and
270 mitigate the need to write direct to the SVSHAPE SPRs.
272 ### FFT/DCT Triple Loop
274 DCT and FFT are some of the most astonishingly used algorithms in
275 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
276 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
279 An in-depth analysis showed that it is possible to do in-place in-register
280 DCT and FFT as long as twin-result "butterfly" instructions are provided.
281 These can be found in the [[openpower/isa/svfparith]] page if performing
282 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
283 integer operations would be required)*. These "butterfly" instructions
284 avoid the need for a temporary register because the two array positions
285 being overwritten will be "in-flight" in any In-Order or Out-of-Order
288 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
289 accept predicate masks. Given that it is common to perform recursive
290 convolutions combining smaller Power-2 DCT/FFT to create larger DCT/FFTs
291 in practice the RADIX2 limit is not a problem. A Bluestein convolution
292 to compute arbitrary length is demonstrated by
293 [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
297 The purpose of Indexing is to provide a generalised version of
298 Vector ISA "Permute" instructions, such as VSX `vperm`. The
299 Indexing is abstracted out and may be applied to much more
300 than an element move/copy, and is not limited for example
301 to the number of bytes that can fit into a VSX register.
302 Indexing may be applied to LD/ST (even on Indexed LD/ST
303 instructions such as `sv.lbzx`), arithmetic operations,
304 extsw: there is no artificial limit.
306 The only major caveat is that the registers to be used as
307 Indices must not be modified by any instruction after Indexed Mode
308 is established, and neither must MAXVL be altered. Additionally,
309 no register used as an Index may exceed MAXVL-1.
312 these conditions results in `UNDEFINED` behaviour.
313 These conditions allow a Read-After-Write (RAW) Hazard to be created on
314 the entire range of Indices to be subsequently used, but a corresponding
315 Write-After-Read Hazard by any instruction that modifies the Indices
316 **does not have to be created**. Given the large number of registers
317 involved in Indexing this is a huge resource saving and reduction
318 in micro-architectural complexity. MAXVL is likewise
319 included in the RAW Hazards because it is involved in calculating
320 how many registers are to be considered Indices.
322 With these Hazard Mitigations in place, high-performance implementations
323 may read-cache the Indices at the point where a given `svindex` instruction
324 is called (or SVSHAPE SPRs - and MAXVL - directly altered) by issuing
325 background GPR register file reads whilst other instructions are being
328 The original motivation for Indexed REMAP was to mitigate the need to add
329 an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
330 a stand-alone instruction. Usually a Vector ISA would add a non-conflicting
331 variant (as in VSX `vperm`) but it is common to need to permute by source,
332 with the risk of conflict, that has to be resolved, for example, in AVX-512
335 Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
336 destinations), which on a superficial analysis may be perceived to be a
337 problem, until it is recalled that, firstly, Simple-V is designed specifically
338 to require Program Order to be respected, and that Matrix, DCT and FFT
339 all *already* critically depend on overlapping Reads/Writes: Matrix
340 uses overlapping registers as accumulators. Thus the Register Hazard
341 Management needed by Indexed REMAP *has* to be in place anyway.
343 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
344 clearly that of the additional reading of the GPRs to be used as Indices,
345 plus the setup cost associated with creating those same Indices.
346 If any Deterministic REMAP can cover the required task, clearly it
347 is adviseable to use it instead.
349 *Programmer's note: some algorithms may require skipping of Indices exceeding
350 VL-1, not MAXVL-1. This may be achieved programmatically by performing
351 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
352 and RB contains the value of VL returned from `setvl`. The resultant
353 CR Fields may then be used as Predicate Masks to exclude those operations
354 with an Index exceeding VL-1.*
356 ### Parallel Reduction
358 Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
359 (Power ISA v3.0B) operation is leveraged, unmodified, to give the
360 *appearance* and *effect* of Reduction.
362 In Horizontal-First Mode, Vector-result reduction **requires**
363 the destination to be a Vector, which will be used to store
364 intermediary results.
366 Given that the tree-reduction schedule is deterministic,
367 Interrupts and exceptions
368 can therefore also be precise. The final result will be in the first
369 non-predicate-masked-out destination element, but due again to
370 the deterministic schedule programmers may find uses for the intermediate
373 When Rc=1 a corresponding Vector of co-resultant CRs is also
374 created. No special action is taken: the result *and its CR Field*
375 are stored "as usual" exactly as all other SVP64 Rc=1 operations.
377 Note that the Schedule only makes sense on top of certain instructions:
378 X-Form with a Register Profile of `RT,RA,RB` is fine because two sources
379 and the destination are all the same type. Like Scalar
380 Reduction, nothing is prohibited:
381 the results of execution on an unsuitable instruction may simply
382 not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
383 may be used, and whilst it is down to the Programmer to walk through the
384 process the Programmer can be confident that the Parallel-Reduction is
385 guaranteed 100% Deterministic.
387 Critical to note regarding use of Parallel-Reduction REMAP is that,
388 exactly as with all REMAP Modes, the `svshape` instruction *requests*
389 a certain Vector Length (number of elements to reduce) and then
390 sets VL and MAXVL at the number of **operations** needed to be
391 carried out. Thus, equally as importantly, like Matrix REMAP
392 the total number of operations
393 is restricted to 127. Any Parallel-Reduction requiring more operations
394 will need to be done manually in batches (hierarchical
395 recursive Reduction).
397 Also important to note is that the Deterministic Schedule is arranged
398 so that some implementations *may* parallelise it (as long as doing so
399 respects Program Order and Register Hazards). Performance (speed)
401 implementation is neither strictly defined or guaranteed. As with
402 the Vulkan(tm) Specification, strict compliance is paramount whilst
403 performance is at the discretion of Implementors.
405 **Parallel-Reduction with Predication**
407 To avoid breaking the strict RISC-paradigm, keeping the Issue-Schedule
408 completely separate from the actual element-level (scalar) operations,
409 Move operations are **not** included in the Schedule. This means that
410 the Schedule leaves the final (scalar) result in the first-non-masked
411 element of the Vector used. With the predicate mask being dynamic
412 (but deterministic) this result could be anywhere.
414 If that result is needed to be moved to a (single) scalar register
415 then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
416 needed to get it, where the predicate is the exact same predicate used
417 in the prior Parallel-Reduction instruction.
419 * If there was only a single
420 bit in the predicate then the result will not have moved or been altered
421 from the source vector prior to the Reduction
422 * If there was more than one bit the result will be in the
423 first element with a predicate bit set.
425 In either case the result is in the element with the first bit set in
428 Programmer's Note: For *some* hardware implementations
429 the vector-to-scalar copy may be a slow operation, as may the Predicated
430 Parallel Reduction itself.
431 It may be better to perform a pre-copy
432 of the values, compressing them (VREDUCE-style) into a contiguous block,
433 which will guarantee that the result goes into the very first element
434 of the destination vector, in which case clearly no follow-up
435 vector-to-scalar MV operation is needed.
439 The simplest usage is to perform an overwrite, specifying all three
440 register operands the same.
443 svshape parallelreduce, 6
447 The Reduction Schedule will issue the Parallel Tree Reduction spanning
448 registers 8 through 13, by adjusting the offsets to RT, RA and RB as
449 necessary (see "Parallel Reduction algorithm" in a later section).
451 A non-overwrite is possible as well but just as with the overwrite
452 version, only those destination elements necessary for storing
453 intermediary computations will be written to: the remaining elements
454 will **not** be overwritten and will **not** be zero'd.
457 svshape parallelreduce, 6
461 However it is critical to note that if the source and destination are
462 not the same then the trick of using a follow-up vector-scalar MV will
465 ### Sub-Vector Horizontal Reduction
467 To achieve Sub-Vector Horizontal Reduction, Pack/Unpack should be enabled,
468 which will turn the Schedule around such that issuing of the Scalar
469 Defined Words is done with SUBVL looping as the inner loop not the
470 outer loop. Rc=1 with Sub-Vectors (SUBVL=2,3,4) is `UNDEFINED` behaviour.
472 ## Determining Register Hazards
474 For high-performance (Multi-Issue, Out-of-Order) systems it is critical
475 to be able to statically determine the extent of Vectors in order to
476 allocate pre-emptive Hazard protection. The next task is to eliminate
477 masked-out elements using predicate bits, freeing up the associated
480 For non-REMAP situations `VL` is sufficient to ascertain early
481 Hazard coverage, and with SVSTATE being a high priority cached
482 quantity at the same level of MSR and PC this is not a problem.
484 The problems come when REMAP is enabled. Indexed REMAP must instead
485 use `MAXVL` as the earliest (simplest)
486 batch-level Hazard Reservation indicator (after taking element-width
487 overriding on the Index source into consideration),
488 but Matrix, FFT and Parallel Reduction must all use completely different
489 schemes. The reason is that VL is used to step through the total
490 number of *operations*, not the number of registers.
491 The "Saving Grace" is that all of the REMAP Schedules are 100% Deterministic.
493 Advance-notice Parallel computation and subsequent cacheing
494 of all of these complex Deterministic REMAP Schedules is
495 *strongly recommended*, thus allowing clear and precise multi-issue
496 batched Hazard coverage to be deployed, *even for Indexed Mode*.
497 This is only possible for Indexed due to the strict guidelines
498 given to Programmers.
500 In short, there exists solutions to the problem of Hazard Management,
501 with varying degrees of refinement possible at correspondingly
502 increasing levels of complexity in hardware.
504 A reminder: when Rc=1 each result register (element) has an associated
505 co-result CR Field (one per result element). Thus above when determining
506 the Write-Hazards for result registers the corresponding Write-Hazards for the
507 corresponding associated co-result CR Field must not be forgotten, *including* when
510 ## REMAP area of SVSTATE SPR
512 The following bits of the SVSTATE SPR are used for REMAP:
514 |32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
515 | -- | -- | -- | -- | -- | ----- | ------ |
516 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
518 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
519 mi0-2 apply to RA, RB, RC respectively, as input registers, and
520 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
521 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
522 SVSHAPE is actively applied or not.
524 * bit 0 of SVme indicates if mi0 is applied to RA / FRA / BA / BFA
525 * bit 1 of SVme indicates if mi1 is applied to RB / FRB / BB
526 * bit 2 of SVme indicates if mi2 is applied to RC / FRC / BC
527 * bit 3 of SVme indicates if mo0 is applied to RT / FRT / BT / BF
528 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
529 (LD/ST-with-update has an implicit 2nd write register, RA)
531 The "persistence" bit if set will result in all Active REMAPs being applied
538 # svremap instruction <a name="svremap"> </a>
542 svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
544 |0 |6 |11 |13 |15 |17 |19 |21 | 22.25 |26..31 |
545 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
546 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
550 * svremap SVme,mi0,mi1,mi2,mo0,mo1,pst
555 # registers RA RB RC RT EA/FRS SVSHAPE0-3 indices
556 SVSTATE[32:33] <- mi0
557 SVSTATE[34:35] <- mi1
558 SVSTATE[36:37] <- mi2
559 SVSTATE[38:39] <- mo0
560 SVSTATE[40:41] <- mo1
561 # enable bit for RA RB RC RT EA/FRS
562 SVSTATE[42:46] <- SVme
563 # persistence bit (applies to more than one instruction)
567 Special Registers Altered:
573 `svremap` determines the relationship between registers and SVSHAPE SPRs.
574 The bitmask `SVme` determines which registers have a REMAP applied, and mi0-mo1
575 determine which shape is applied to an activated register. the `pst` bit if
576 cleared indicated that the REMAP operation shall only apply to the immediately-following
577 instruction. If set then REMAP remains permanently enabled until such time as it is
578 explicitly disabled, either by `setvl` setting a new MAXVL, or with another
579 `svremap` instruction. `svindex` and `svshape2` are also capable of setting or
580 clearing persistence, as well as partially covering a subset of the capability of
581 `svremap` to set register-to-SVSHAPE relationships.
583 Programmer's Note: applying non-persistent `svremap` to an instruction that has
584 no REMAP enabled or is a Scalar operation will obviously have no effect but
585 the bits 32 to 46 will at least have been set in SVSTATE. This may prove useful
586 when using `svindex` or `svshape2`.
588 Hardware Architectural Note: when persistence is not set it is critically important
589 to treat the `svremap` and the following SVP64 instruction as an indivisible fused operation.
590 *No state* is stored in the SVSTATE SPR in order to allow continuation should an
591 Interrupt occur between the two instructions. Thus, Interrupts must be prohibited
592 from occurring or other workaround deployed. When persistence is set this issue
595 It is critical to note that if persistence is clear `svremap` is the **only** way
596 to activate REMAP on any given (following) instruction. If persistence is set however then
597 **all** SVP64 instructions go through REMAP as long as `SVme` is non-zero.
603 # SHAPE Remapping SPRs
605 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
606 which have the same format.
608 Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
609 disabled: the register's elements are a linear (1D) vector.
611 |31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
612 |---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
613 |0b00 |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
614 |0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
615 |0b01 |submode|offset| invxyz | submode2| zdimsz |mode |xdimsz|DCT/FFT|
616 |0b10 |submode|offset| invxyz | rsvd | rsvd |rsvd |xdimsz|Preduce|
617 |0b11 | | | | | | | |rsvd |
619 mode sets different behaviours (straight matrix multiply, FFT, DCT).
621 * **mode=0b00** sets straight Matrix Mode
622 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
623 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
624 * **mode=0b10** sets "Parallel Reduction" Schedules.
626 ## Parallel Reduction Mode
628 Creates the Schedules for Parallel Tree Reduction.
630 * **submode=0b00** selects the left operand index
631 * **submode=0b01** selects the right operand index
633 * When bit 0 of `invxyz` is set, the order of the indices
634 in the inner for-loop are reversed. This has the side-effect
635 of placing the final reduced result in the last-predicated element.
636 It also has the indirect side-effect of swapping the source
637 registers: Left-operand index numbers will always exceed
638 Right-operand indices.
639 When clear, the reduced result will be in the first-predicated
640 element, and Left-operand indices will always be *less* than
642 * When bit 1 of `invxyz` is set, the order of the outer loop
643 step is inverted: stepping begins at the nearest power-of two
644 to half of the vector length and reduces by half each time.
645 When clear the step will begin at 2 and double on each
650 submode2=0 is for FFT. For FFT submode the following schedules may be
653 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
655 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
657 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
659 When submode2 is 1 or 2, for DCT inner butterfly submode the following
660 schedules may be selected. When submode2 is 1, additional bit-reversing
663 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
665 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
666 in reverse-order, in-place
667 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
668 useful for calculating the cosine coefficient
669 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
670 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
672 When submode2 is 3 or 4, for DCT outer butterfly submode the following
673 schedules may be selected. When submode is 3, additional bit-reversing
676 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
677 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
679 `zdimsz` is used as an in-place "Stride", particularly useful for
680 column-based in-place DCT/FFT.
684 In Matrix Mode, skip allows dimensions to be skipped from being included
685 in the resultant output index. this allows sequences to be repeated:
686 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
687 modulo ```0 1 2 0 1 2 ...```
689 * **skip=0b00** indicates no dimensions to be skipped
690 * **skip=0b01** sets "skip 1st dimension"
691 * **skip=0b10** sets "skip 2nd dimension"
692 * **skip=0b11** sets "skip 3rd dimension"
694 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
695 zero then x-dimensional counting begins from 0 and increments, otherwise
696 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
698 offset will have the effect of offsetting the result by ```offset``` elements:
702 GPR(RT + remap(i) + SVSHAPE.offset) = ....
705 this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
706 bear in mind that unlike a static compiler SVSHAPE.offset may
707 be set dynamically at runtime.
709 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
710 that the array dimensionality for that dimension is 1. any dimension
711 not intended to be used must have its value set to 0 (dimensionality
712 of 1). A value of xdimsz=2 would indicate that in the first dimension
713 there are 3 elements in the array. For example, to create a 2D array
714 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
716 The format of the array is therefore as follows:
719 array[xdimsz+1][ydimsz+1][zdimsz+1]
722 However whilst illustrative of the dimensionality, that does not take the
723 "permute" setting into account. "permute" may be any one of six values
724 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
725 below shows how the permutation dimensionality order works:
727 | permute | order | array format |
728 | ------- | ----- | ------------------------ |
729 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
730 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
731 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
732 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
733 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
734 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
735 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
736 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
738 In other words, the "permute" option changes the order in which
739 nested for-loops over the array would be done. See executable
740 python reference code for further details.
742 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
745 With all these options it is possible to support in-place transpose,
746 in-place rotate, Matrix Multiply and Convolutions, without being
747 limited to Power-of-Two dimension sizes.
751 Indexed Mode activates reading of the element indices from the GPR
752 and includes optional limited 2D reordering.
753 In its simplest form (without elwidth overrides or other modes):
757 return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
760 element_result = ....
761 GPR(RT + indexed_remap(i)) = element_result
764 With element-width overrides included, and using the pseudocode
765 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
770 svreg = SVSHAPE.SVGPR << 1
771 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
772 offs = SVSHAPE.offset
773 return get_polymorphed_reg(svreg, srcwid, i) + offs
776 element_result = ....
777 rt_idx = indexed_remap(i)
778 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
781 Matrix-style reordering still applies to the indices, except limited
782 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
783 (Y,X) for in-place Transposition.
784 Only one dimension may optionally be skipped. Inversion of either
785 X or Y or both is possible (2D mirroring). Pseudocode for Indexed Mode (including elwidth
786 overrides) may be written in terms of Matrix Mode, specifically
787 purposed to ensure that the 3rd dimension (Z) has no effect:
790 def index_remap(ISHAPE, i):
791 MSHAPE.skip = 0b0 || ISHAPE.sk1
792 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
793 MSHAPE.xdimsz = ISHAPE.xdimsz
794 MSHAPE.ydimsz = ISHAPE.ydimsz
795 MSHAPE.zdimsz = 0 # disabled
796 if ISHAPE.permute = 0b110 # 0,1
797 MSHAPE.permute = 0b000 # 0,1,2
798 if ISHAPE.permute = 0b111 # 1,0
799 MSHAPE.permute = 0b010 # 1,0,2
800 el_idx = remap_matrix(MSHAPE, i)
801 svreg = ISHAPE.SVGPR << 1
802 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
804 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
807 The most important observation above is that the Matrix-style
808 remapping occurs first and the Index lookup second. Thus it
809 becomes possible to perform in-place Transpose of Indices which
810 may have been costly to set up or costly to duplicate
811 (waste register file space).
817 # svshape instruction <a name="svshape"> </a>
819 Form: SVM-Form SV "Matrix" Form (see [[isatables/fields.text]])
821 svshape SVxd,SVyd,SVzd,SVRM,vf
823 | 0.5|6.10 |11.15 |16..20 | 21..24 | 25 | 26..31| name |
824 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
825 |OPCD| SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
828 # for convenience, VL to be calculated and stored in SVSTATE
830 mscale[0:5] <- 0b000001 # for scaling MAXVL
831 itercount[0:6] <- [0] * 7
832 SVSTATE[0:31] <- [0] * 32
833 # only overwrite REMAP if "persistence" is zero
834 if (SVSTATE[62] = 0b0) then
835 SVSTATE[32:33] <- 0b00
836 SVSTATE[34:35] <- 0b00
837 SVSTATE[36:37] <- 0b00
838 SVSTATE[38:39] <- 0b00
839 SVSTATE[40:41] <- 0b00
840 SVSTATE[42:46] <- 0b00000
843 # clear out all SVSHAPEs
844 SVSHAPE0[0:31] <- [0] * 32
845 SVSHAPE1[0:31] <- [0] * 32
846 SVSHAPE2[0:31] <- [0] * 32
847 SVSHAPE3[0:31] <- [0] * 32
849 # set schedule up for multiply
850 if (SVrm = 0b0000) then
851 # VL in Matrix Multiply is xd*yd*zd
852 xd <- (0b00 || SVxd) + 1
853 yd <- (0b00 || SVyd) + 1
854 zd <- (0b00 || SVzd) + 1
856 vlen[0:6] <- n[14:20]
857 # set up template in SVSHAPE0, then copy to 1-3
858 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
859 SVSHAPE0[6:11] <- (0b0 || SVyd) # ydim
860 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim
861 SVSHAPE0[28:29] <- 0b11 # skip z
863 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
864 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
865 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
867 SVSHAPE1[18:20] <- 0b001 # permute x,z,y
868 SVSHAPE1[28:29] <- 0b01 # skip z
870 SVSHAPE2[18:20] <- 0b001 # permute x,z,y
871 SVSHAPE2[28:29] <- 0b11 # skip y
873 # set schedule up for FFT butterfly
874 if (SVrm = 0b0001) then
875 # calculate O(N log2 N)
878 if SVxd[4-n] = 0 then
881 n <- ((0b0 || SVxd) + 1) * n
883 # set up template in SVSHAPE0, then copy to 1-3
885 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
886 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D FFT)
887 mscale <- (0b0 || SVzd) + 1
888 SVSHAPE0[30:31] <- 0b01 # Butterfly mode
890 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
891 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
893 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
895 SVSHAPE2[28:29] <- 0b10 # k schedule
897 # set schedule up for (i)DCT Inner butterfly
898 # SVrm Mode 4 (Mode 12 for iDCT) is for on-the-fly (Vertical-First Mode)
899 if ((SVrm = 0b0100) |
900 (SVrm = 0b1100)) then
901 # calculate O(N log2 N)
904 if SVxd[4-n] = 0 then
907 n <- ((0b0 || SVxd) + 1) * n
909 # set up template in SVSHAPE0, then copy to 1-3
911 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
912 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
913 mscale <- (0b0 || SVzd) + 1
914 if (SVrm = 0b1100) then
915 SVSHAPE0[30:31] <- 0b11 # iDCT mode
916 SVSHAPE0[18:20] <- 0b011 # iDCT Inner Butterfly sub-mode
918 SVSHAPE0[30:31] <- 0b01 # DCT mode
919 SVSHAPE0[18:20] <- 0b001 # DCT Inner Butterfly sub-mode
920 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop
921 SVSHAPE0[6:11] <- 0b000011 # (i)DCT Inner Butterfly mode 4
923 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
924 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
925 if (SVrm != 0b0100) & (SVrm != 0b1100) then
926 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
928 SVSHAPE0[28:29] <- 0b01 # j+halfstep schedule
929 # for cos coefficient
930 SVSHAPE2[28:29] <- 0b10 # ci (k for mode 4) schedule
931 SVSHAPE2[12:17] <- 0b000000 # reset costable "striding" to 1
932 if (SVrm != 0b0100) & (SVrm != 0b1100) then
933 SVSHAPE3[28:29] <- 0b11 # size schedule
935 # set schedule up for (i)DCT Outer butterfly
936 if (SVrm = 0b0011) | (SVrm = 0b1011) then
937 # calculate O(N log2 N) number of outer butterfly overlapping adds
941 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
942 itercount[0:6] <- (0b0 || itercount[0:5])
944 if SVxd[4-n] = 0 then
947 count <- (itercount - 0b0000001) * size
948 vlen[0:6] <- vlen + count[7:13]
949 size[0:6] <- (size[1:6] || 0b0)
950 itercount[0:6] <- (0b0 || itercount[0:5])
951 # set up template in SVSHAPE0, then copy to 1-3
953 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
954 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
955 mscale <- (0b0 || SVzd) + 1
956 if (SVrm = 0b1011) then
957 SVSHAPE0[30:31] <- 0b11 # iDCT mode
958 SVSHAPE0[18:20] <- 0b011 # iDCT Outer Butterfly sub-mode
959 SVSHAPE0[21:23] <- 0b101 # "inverse" on outer and inner loop
961 SVSHAPE0[30:31] <- 0b01 # DCT mode
962 SVSHAPE0[18:20] <- 0b100 # DCT Outer Butterfly sub-mode
963 SVSHAPE0[6:11] <- 0b000010 # DCT Butterfly mode
965 SVSHAPE1[0:31] <- SVSHAPE0[0:31] # j+halfstep schedule
966 SVSHAPE2[0:31] <- SVSHAPE0[0:31] # costable coefficients
968 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
969 # reset costable "striding" to 1
970 SVSHAPE2[12:17] <- 0b000000
972 # set schedule up for DCT COS table generation
973 if (SVrm = 0b0101) | (SVrm = 0b1101) then
974 # calculate O(N log2 N)
976 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
977 itercount[0:6] <- (0b0 || itercount[0:5])
980 if SVxd[4-n] = 0 then
983 vlen[0:6] <- vlen + itercount
984 itercount[0:6] <- (0b0 || itercount[0:5])
985 # set up template in SVSHAPE0, then copy to 1-3
987 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
988 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
989 mscale <- (0b0 || SVzd) + 1
990 SVSHAPE0[30:31] <- 0b01 # DCT/FFT mode
991 SVSHAPE0[6:11] <- 0b000100 # DCT Inner Butterfly COS-gen mode
992 if (SVrm = 0b0101) then
993 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop for DCT
995 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
996 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
997 # for cos coefficient
998 SVSHAPE1[28:29] <- 0b10 # ci schedule
999 SVSHAPE2[28:29] <- 0b11 # size schedule
1001 # set schedule up for iDCT / DCT inverse of half-swapped ordering
1002 if (SVrm = 0b0110) | (SVrm = 0b1110) | (SVrm = 0b1111) then
1003 vlen[0:6] <- (0b00 || SVxd) + 0b0000001
1004 # set up template in SVSHAPE0
1005 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
1006 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
1007 mscale <- (0b0 || SVzd) + 1
1008 if (SVrm = 0b1110) then
1009 SVSHAPE0[18:20] <- 0b001 # DCT opposite half-swap
1010 if (SVrm = 0b1111) then
1011 SVSHAPE0[30:31] <- 0b01 # FFT mode
1013 SVSHAPE0[30:31] <- 0b11 # DCT mode
1014 SVSHAPE0[6:11] <- 0b000101 # DCT "half-swap" mode
1016 # set schedule up for parallel reduction
1017 if (SVrm = 0b0111) then
1018 # calculate the total number of operations (brute-force)
1019 vlen[0:6] <- [0] * 7
1020 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
1021 step[0:6] <- 0b0000001
1023 do while step <u itercount
1024 newstep <- step[1:6] || 0b0
1026 do while (j+step <u itercount)
1030 # VL in Parallel-Reduce is the number of operations
1032 # set up template in SVSHAPE0, then copy to 1. only 2 needed
1033 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
1034 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
1035 mscale <- (0b0 || SVzd) + 1
1036 SVSHAPE0[30:31] <- 0b10 # parallel reduce submode
1038 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
1039 # set up right operand (left operand 28:29 is zero)
1040 SVSHAPE1[28:29] <- 0b01 # right operand
1042 # set VL, MVL and Vertical-First
1043 m[0:12] <- vlen * mscale
1044 maxvl[0:6] <- m[6:12]
1045 SVSTATE[0:6] <- maxvl # MAVXL
1046 SVSTATE[7:13] <- vlen # VL
1050 Special Registers Altered:
1056 `svshape` is a convenience instruction that reduces instruction
1057 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
1058 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
1059 including VL and MAXVL. Using `svshape` therefore does not also
1064 * **SVxd** - SV REMAP "xdim"
1065 * **SVyd** - SV REMAP "ydim"
1066 * **SVzd** - SV REMAP "zdim"
1067 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
1068 * **vf** - sets "Vertical-First" mode
1070 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
1071 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
1073 There are 12 REMAP Modes (2 Modes are RESERVED for `svshape2`, 2 Modes
1076 | SVRM | Remap Mode description |
1078 | 0b0000 | Matrix 1/2/3D |
1079 | 0b0001 | FFT Butterfly |
1080 | 0b0010 | reserved |
1081 | 0b0011 | DCT Outer butterfly |
1082 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1083 | 0b0101 | DCT COS table index generation |
1084 | 0b0110 | DCT half-swap |
1085 | 0b0111 | Parallel Reduction |
1086 | 0b1000 | reserved for svshape2 |
1087 | 0b1001 | reserved for svshape2 |
1088 | 0b1010 | reserved |
1089 | 0b1011 | iDCT Outer butterfly |
1090 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1091 | 0b1101 | iDCT COS table index generation |
1092 | 0b1110 | iDCT half-swap |
1093 | 0b1111 | FFT half-swap |
1095 Examples showing how all of these Modes operate exists in the online
1096 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD). Explaining
1097 these Modes further in detail is beyond the scope of this document.
1099 In Indexed Mode, there are only 5 bits available to specify the GPR
1100 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
1101 5 bits are given in the `SVxd` field: the bottom two implicit bits
1102 will be zero (`SVxd || 0b00`).
1104 `svshape` has *limited applicability* due to being a 32-bit instruction.
1105 The full capability of SVSHAPE SPRs may be accessed by directly writing
1106 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
1107 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
1108 instruction, `psvshape`, may extend the capability here.
1110 *Architectural Resource Allocation note: the SVRM field is carefully
1111 crafted to allocate two Modes, corresponding to bits 21-23 within the
1112 instruction being set to the value `0b100`, to `svshape2` (not
1113 `svshape`). These two Modes are
1114 considered "RESERVED" within the context of `svshape` but it is
1115 absolutely critical to allocate the exact same pattern in XO for
1116 both instructions in bits 26-31.*
1123 # svindex instruction <a name="svindex"> </a>
1127 | 0-5|6-10 |11-15 |16-20 | 21-25 | 26-31 | Form |
1128 | -- | -- | --- | ---- | ----------- | ------| -------- |
1129 | PO | SVG | rmm | SVd | ew/yx/mm/sk | XO | SVI-Form |
1131 * svindex SVG,rmm,SVd,ew,SVyx,mm,sk
1136 # based on nearest MAXVL compute other dimension
1140 do while d*dim <u ([0]*4 || MVL)
1143 # set up template, then copy once location identified
1145 shape[30:31] <- 0b00 # mode
1147 shape[18:20] <- 0b110 # indexed xd/yd
1148 shape[0:5] <- (0b0 || SVd) # xdim
1149 if sk = 0 then shape[6:11] <- 0 # ydim
1150 else shape[6:11] <- 0b111111 # ydim max
1152 shape[18:20] <- 0b111 # indexed yd/xd
1153 if sk = 1 then shape[6:11] <- 0 # ydim
1154 else shape[6:11] <- d-1 # ydim max
1155 shape[0:5] <- (0b0 || SVd) # ydim
1156 shape[12:17] <- (0b0 || SVG) # SVGPR
1157 shape[28:29] <- ew # element-width override
1158 shape[21] <- sk # skip 1st dimension
1160 # select the mode for updating SVSHAPEs
1161 SVSTATE[62] <- mm # set or clear persistence
1163 # clear out all SVSHAPEs first
1164 SVSHAPE0[0:31] <- [0] * 32
1165 SVSHAPE1[0:31] <- [0] * 32
1166 SVSHAPE2[0:31] <- [0] * 32
1167 SVSHAPE3[0:31] <- [0] * 32
1168 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1169 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1173 # activate requested shape
1174 if idx = 0 then SVSHAPE0 <- shape
1175 if idx = 1 then SVSHAPE1 <- shape
1176 if idx = 2 then SVSHAPE2 <- shape
1177 if idx = 3 then SVSHAPE3 <- shape
1178 SVSTATE[bit*2+32:bit*2+33] <- idx
1179 # increment shape index, modulo 4
1180 if idx = 3 then idx <- 0
1183 # refined SVSHAPE/REMAP update mode
1186 if idx = 0 then SVSHAPE0 <- shape
1187 if idx = 1 then SVSHAPE1 <- shape
1188 if idx = 2 then SVSHAPE2 <- shape
1189 if idx = 3 then SVSHAPE3 <- shape
1190 SVSTATE[bit*2+32:bit*2+33] <- idx
1191 SVSTATE[46-bit] <- 1
1194 Special Registers Altered:
1200 `svindex` is a convenience instruction that reduces instruction count
1201 for Indexed REMAP Mode. It sets up (overwrites) all required SVSHAPE
1202 SPRs and **unlike** `svshape` can modify the REMAP area of the SVSTATE
1203 SPR as well, including setting persistence. The relevant SPRs *may*
1204 be directly programmed with `mtspr` however it is laborious to do so:
1205 svindex saves instructions covering much of Indexed REMAP capability.
1209 * **SVd** - SV REMAP x/y dim
1210 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
1212 * **ew** - sets element width override on the Indices
1213 * **SVG** - GPR SVG<<2 to be used for Indexing
1214 * **yx** - 2D reordering to be used if yx=1
1215 * **mm** - mask mode. determines how `rmm` is interpreted.
1216 * **sk** - Dimension skipping enabled
1218 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
1219 "off-by-one". In the assembler
1220 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
1222 *Note: when `yx=1,sk=0` the second dimension is calculated as
1227 * `rmm`, like REMAP.SVme, has bit 0
1228 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
1229 bit 3 to mo0 and bit 4 to mi1
1230 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
1231 * for each bit set in the 5-bit `rmm`, in order, the first
1232 as-yet-unset SVSHAPE will be updated
1233 with the other operands in the instruction, and the REMAP
1235 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
1236 * SVSTATE persistence bit is cleared
1237 * No other alterations to SVSTATE are carried out
1239 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
1240 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
1241 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
1242 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
1244 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
1245 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
1246 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
1248 Rough algorithmic form:
1251 marray = [mi0, mi1, mi2, mo0, mo1]
1254 if not rmm[bit]: continue
1256 SVSTATE{marray[bit]} = idx
1257 idx = (idx+1) modulo 4
1262 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
1263 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
1265 * only the selected SVSHAPE is overwritten
1266 * only the relevant bits in the REMAP area of SVSTATE are updated
1267 * REMAP persistence bit is set.
1269 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
1270 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
1271 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
1272 set to 2 (SVSHAPE2).
1274 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
1275 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
1276 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
1277 set to 3 (SVSHAPE3).
1279 Rough algorithmic form:
1282 marray = [mi0, mi1, mi2, mo0, mo1]
1286 SVSTATE{marray[bit]} = idx
1290 In essence, `mm=0` is intended for use to set as much of the
1291 REMAP State SPRs as practical with a single instruction,
1292 whilst `mm=1` is intended to be a little more refined.
1294 **Usage guidelines**
1296 * **Disable 2D mapping**: to only perform Indexing without
1297 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
1299 * **Modulo 1D mapping**: to perform Indexing cycling through the
1300 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
1301 no requirement to set VL equal to a multiple of N.
1302 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
1303 `xdim=M,ydim=CEIL(MAXVL/M)`.
1305 Beyond these mappings it becomes necessary to write directly to
1306 the SVSTATE SPRs manually.
1313 # svshape2 (offset-priority) <a name="svshape2"> </a>
1317 | 0-5|6-9 |10|11-15 |16-20 | 21-24 | 25 | 26-31 | Form |
1318 | -- |----|--| --- | ----- | ------ | -- | ------| -------- |
1319 | PO |offs|yx| rmm | SVd | 100/mm | sk | XO | SVM2-Form |
1321 * svshape2 offs,yx,rmm,SVd,sk,mm
1326 # based on nearest MAXVL compute other dimension
1330 do while d*dim <u ([0]*4 || MVL)
1332 # set up template, then copy once location identified
1334 shape[30:31] <- 0b00 # mode
1335 shape[0:5] <- (0b0 || SVd) # x/ydim
1337 shape[18:20] <- 0b000 # ordering xd/yd(/zd)
1338 if sk = 0 then shape[6:11] <- 0 # ydim
1339 else shape[6:11] <- 0b111111 # ydim max
1341 shape[18:20] <- 0b010 # ordering yd/xd(/zd)
1342 if sk = 1 then shape[6:11] <- 0 # ydim
1343 else shape[6:11] <- d-1 # ydim max
1344 # offset (the prime purpose of this instruction)
1345 shape[24:27] <- SVo # offset
1346 if sk = 1 then shape[28:29] <- 0b01 # skip 1st dimension
1347 else shape[28:29] <- 0b00 # no skipping
1348 # select the mode for updating SVSHAPEs
1349 SVSTATE[62] <- mm # set or clear persistence
1351 # clear out all SVSHAPEs first
1352 SVSHAPE0[0:31] <- [0] * 32
1353 SVSHAPE1[0:31] <- [0] * 32
1354 SVSHAPE2[0:31] <- [0] * 32
1355 SVSHAPE3[0:31] <- [0] * 32
1356 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1357 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1361 # activate requested shape
1362 if idx = 0 then SVSHAPE0 <- shape
1363 if idx = 1 then SVSHAPE1 <- shape
1364 if idx = 2 then SVSHAPE2 <- shape
1365 if idx = 3 then SVSHAPE3 <- shape
1366 SVSTATE[bit*2+32:bit*2+33] <- idx
1367 # increment shape index, modulo 4
1368 if idx = 3 then idx <- 0
1371 # refined SVSHAPE/REMAP update mode
1374 if idx = 0 then SVSHAPE0 <- shape
1375 if idx = 1 then SVSHAPE1 <- shape
1376 if idx = 2 then SVSHAPE2 <- shape
1377 if idx = 3 then SVSHAPE3 <- shape
1378 SVSTATE[bit*2+32:bit*2+33] <- idx
1379 SVSTATE[46-bit] <- 1
1382 Special Registers Altered:
1388 `svshape2` is an additional convenience instruction that prioritises
1389 setting `SVSHAPE.offset`. Its primary purpose is for use when
1390 element-width overrides are used. It has identical capabilities to `svindex` and
1391 in terms of both options (skip, etc.) and ability to activate REMAP
1392 (rmm, mask mode) but unlike `svindex` it does not set GPR REMAP,
1393 only a 1D or 2D `svshape`, and
1394 unlike `svshape` it can set an arbirrary `SVSHAPE.offset` immediate.
1396 One of the limitations of Simple-V is that Vector elements start on the boundary
1397 of the Scalar regfile, which is fine when element-width overrides are not
1398 needed. If the starting point of a Vector with smaller elwidths must begin
1399 in the middle of a register, normally there would be no way to do so except
1400 through LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`is
1405 * **offs** (4 bits) - unsigned offset
1406 * **yx** (1 bit) - swap XY to YX
1407 * **SVd** dimension size
1408 * **rmm** REMAP mask
1410 * **sk** (1 bit) skips 1st dimension if set
1412 Dimensions are calculated exactly as `svindex`. `rmm` and
1413 `mm` are as per `svindex`.
1415 *Programmer's Note: offsets for `svshape2` may be specified in the range
1416 0-15. Given that the principle of Simple-V is to fit on top of
1417 byte-addressable register files and that GPR and FPR are 64-bit (8 bytes)
1418 it should be clear that the offset may, when `elwidth=8`, begin an
1419 element-level operation starting element zero at any arbitrary byte.
1420 On cursory examination attempting to go beyond the range 0-7 seems
1421 unnecessary given that the **next GPR or FPR** is an
1422 alias for an offset in the range 8-15. Thus by simply increasing
1423 the starting Vector point of the operation to the next register it
1424 can be seen that the offset of 0-7 would be sufficient. Unfortunately
1425 however some operations are EXTRA2-encoded it is **not possible**
1426 to increase the GPR/FPR register number by one, because EXTRA2-encoding
1427 of GPR/FPR Vector numbers are restricted to even numbering.
1428 For CR Fields the EXTRA2 encoding is even more sparse.
1429 The additional offset range (8-15) helps overcome these limitations.*
1431 *Hardware Implementor's note: with the offsets only being immediates
1432 and with register numbering being entirely immediate as well it is
1433 possible to correctly compute Register Hazards without requiring
1434 reading the contents of any SPRs. If however there are
1435 instructions that have directly written to the SVSTATE or SVSHAPE
1436 SPRs and those instructions are still in-flight then this position
1437 is clearly **invalid**. This is why Programmers are strongly
1438 discouraged from directly writing to these SPRs.*
1440 *Architectural Resource Allocation note: this instruction shares
1441 the space of `svshape`. Therefore it is critical that the two
1442 instructions, `svshape` and `svshape2` have the exact same XO
1443 in bits 26 thru 31. It is also critical that for `svshape2`,
1444 bit 21 of XO is a 1, bit 22 of XO is a 0, and bit 23 of XO is a 0.*
1452 Add `SVI, SVM, SVRM` to `XO (26:31)` Field in Book I, 1.6.2
1454 Add the following to Book I, 1.6.1, SVI-Form
1457 |0 |6 |11 |16 |21 |23 |24|25|26 31|
1458 | PO | SVG|rmm | SVd |ew |SVyx|mm|sk| XO |
1461 Add the following to Book I, 1.6.1, SVM-Form
1464 |0 |6 |11 |16 |21 |25 |26 |31 |
1465 | PO | SVxd | SVyd | SVzd | SVrm |vf | XO |
1468 Add the following to Book I, 1.6.1, SVM2-Form
1471 |0 |6 |10 |11 |16 |21 |24|25 |26 |31 |
1472 | PO | SVo |SVyx| rmm | SVd |XO |mm|sk | XO |
1475 Add the following to Book I, 1.6.1, SVRM-Form
1478 |0 |6 |11 |13 |15 |17 |19 |21 |22 |26 |31 |
1479 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 |pst |/// | XO |
1482 Add the following to Book I, 1.6.2
1486 Field used in REMAP to select the SVSHAPE for 1st input register
1489 Field used in REMAP to select the SVSHAPE for 2nd input register
1492 Field used in REMAP to select the SVSHAPE for 3rd input register
1495 Field used to specify the meaning of the rmm field for SVI-Form
1499 Field used in REMAP to select the SVSHAPE for 1st output register
1502 Field used in REMAP to select the SVSHAPE for 2nd output register
1505 Field used in REMAP to indicate "persistence" mode (REMAP
1506 continues to apply to multiple instructions)
1509 REMAP Mode field for SVI-Form and SVM2-Form
1512 Field used to specify dimensional skipping in svindex
1515 Immediate field used to specify the size of the REMAP dimension
1516 in the svindex and svshape2 instructions
1519 Immediate field used to specify a 9-bit signed
1520 two's complement integer which is concatenated
1521 on the right with 0b00 and sign-extended to 64 bits.
1524 Field used to specify a GPR to be used as a
1525 source for indexing.
1528 Simple-V immediate field for setting VL or MVL
1531 Simple-V "REMAP" map-enable bits (0-4)
1534 Field used by the svshape2 instruction as an offset
1537 Simple-V "REMAP" Mode
1540 Simple-V "REMAP" x-dimension size
1543 Simple-V "REMAP" y-dimension size
1546 Simple-V "REMAP" z-dimension size
1549 Extended opcode field. Note that bit 21 must be 1, 22 and 23
1550 must be zero, and bits 26-31 must be exactly the same as
1557 Appendix E Power ISA sorted by opcode
1558 Appendix F Power ISA sorted by version
1559 Appendix G Power ISA sorted by Compliancy Subset
1560 Appendix H Power ISA sorted by mnemonic
1562 | Form | Book | Page | Version | mnemonic | Description |
1563 |------|------|------|---------|----------|-------------|
1564 | SVRM | I | # | 3.0B | svremap | REMAP enabling instruction |
1565 | SVM | I | # | 3.0B | svshape | REMAP shape instruction |
1566 | SVM2 | I | # | 3.0B | svshape2 | REMAP shape instruction (2) |
1567 | SVI | I | # | 3.0B | svindex | REMAP General-purpose Indexing |