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 For more general reordering an Indexed REMAP mode is available.
94 REMAP allows the usual vector loop `0..VL-1` to be "reshaped" (re-mapped)
95 from a linear form to a 2D or 3D transposed form, or "offset" to permit
96 arbitrary access to elements (when elwidth overrides are used),
97 independently on each Vector src or dest
98 register. Aside from Indexed REMAP this is entirely Hardware-accelerated
99 reordering and consequently not costly in terms of register access. It
100 will however place a burden on Multi-Issue systems but no more than if
101 the equivalent Scalar instructions were explicitly
102 loop-unrolled without SVP64, and some advanced implementations may even find
103 the Deterministic nature of the Scheduling to be easier on resources.
105 The initial primary motivation of REMAP was for Matrix Multiplication, reordering
106 of sequential data in-place: in-place DCT and FFT were easily justified given the
107 high usage in Computer Science.
108 Four SPRs are provided which may be applied to any GPR, FPR or CR Field
109 so that for example a single FMAC may be
110 used in a single hardware-controlled 100% Deterministic loop to
111 perform 5x3 times 3x4 Matrix multiplication,
112 generating 60 FMACs *without needing explicit assembler unrolling*.
113 Additional uses include regular "Structure Packing"
114 such as RGB pixel data extraction and reforming.
116 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
117 Vector ISAs which would typically only have a limited set of instructions
118 that can be structure-packed (LD/ST typically), REMAP may be applied to
119 literally any instruction: CRs, Arithmetic, Logical, LD/ST, anything.
121 Note that REMAP does not *directly* apply to sub-vector elements: that
122 is what swizzle is for. Swizzle *can* however be applied to the same
123 instruction as REMAP. As explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack EXTRA Mode bits
124 can extend down into Sub-vector elements to perform vec2/vec3/vec4
125 sequential reordering, but even here, REMAP is not extended down to
126 the actual sub-vector elements themselves.
128 In its general form, REMAP is quite expensive to set up, and on some
129 implementations may introduce
130 latency, so should realistically be used only where it is worthwhile.
131 Commonly-used patterns such as Matrix Multiply, DCT and FFT have
132 helper instruction options which make REMAP easier to use.
134 There are four types of REMAP:
136 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
137 Matrix transpose and rotate. The Shapes are set up for an "Outer Product"
139 * **FFT/DCT**, with full triple-loop in-place support: limited to
141 * **Indexing**, for any general-purpose reordering, also includes
142 limited 2D reshaping.
143 * **Parallel Reduction**, for scheduling a sequence of operations
144 in a Deterministic fashion, in a way that may be parallelised,
145 to reduce a Vector down to a single value.
147 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
148 REMAP Schedules are 100% Deterministic **including Indexing** and are
149 designed to be incorporated in between the Decode and Issue phases,
150 directly into Register Hazard Management.
152 Parallel Reduction is unusual in that it requires a full vector array
153 of results (not a scalar) and uses the rest of the result Vector for
154 the purposes of storing intermediary calculations. As these intermediary
155 results are Deterministically computed they may be useful.
156 Additionally, because the intermediate results are always written out
157 it is possible to service Precise Interrupts without affecting latency
158 (a common limitation of Vector ISAs implementing explicit
159 Parallel Reduction instructions).
163 * normal vector element read/write of operands would be sequential
165 * this is not appropriate for (e.g.) Matrix multiply which requires
166 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
167 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
168 with this. both are expensive (copy large vectors, spill through memory)
169 and very few Packed SIMD ISAs cope with non-Power-2.
170 * REMAP **redefines** the order of access according to set
171 (Deterministic) "Schedules".
172 * The Schedules are not at all restricted to power-of-two boundaries
173 making it unnecessary to have for example specialised 3x4 transpose
174 instructions of other Vector ISAs.
176 Only the most commonly-used algorithms in computer science have REMAP
177 support, due to the high cost in both the ISA and in hardware. For
178 arbitrary remapping the `Indexed` REMAP may be used.
182 * `svshape` to set the type of reordering to be applied to an
183 otherwise usual `0..VL-1` hardware for-loop
184 * `svremap` to set which registers a given reordering is to apply to
186 * `sv.{instruction}` where any Vectorised register marked by `svremap`
187 will have its ordering REMAPPED according to the schedule set
190 The following illustrative example multiplies a 3x4 and a 5x3
195 svshape 5, 4, 3, 0, 0
196 svremap 15, 1, 2, 3, 0, 0, 0, 0
197 sv.fmadds *0, *8, *16, *0
200 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
201 * svremap activates four out of five registers RA RB RC RT RS (15)
207 - RS Remapping to not be activated
208 * sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
209 * With REMAP being active each register's element index is
210 *independently* transformed using the specified SHAPEs.
212 Thus the Vector Loop is arranged such that the use of
213 the multiply-and-accumulate instruction executes precisely the required
214 Schedule to perform an in-place in-registers Matrix Multiply with no
215 need to perform additional Transpose or register copy instructions.
216 The example above may be executed as a unit test and demo,
217 [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)
221 This section summarises the motivation for each REMAP Schedule
222 and briefly goes over their characteristics and limitations.
223 Further details on the Deterministic Precise-Interruptible algorithms
224 used in these Schedules is found in the [[sv/remap/appendix]].
226 ### Matrix (1D/2D/3D shaping)
228 Matrix Multiplication is a huge part of High-Performance Compute,
230 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
231 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
232 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
233 Aside from the cost of the load on the L1 I-Cache, the trick only
234 works if one of the dimensions X or Y are power-two. Prime Numbers
235 (5x7, 3x5) become deeply problematic to unroll.
237 Even traditional Scalable Vector ISAs have issues with Matrices, often
238 having to perform data Transpose by pushing out through Memory and back,
239 or computing Transposition Indices (costly) then copying to another
242 Matrix REMAP was thus designed to solve these issues by providing Hardware
244 "Schedules" that can view what would otherwise be limited to a strictly
245 linear Vector as instead being 2D (even 3D) *in-place* reordered.
246 With both Transposition and non-power-two being supported the issues
247 faced by other ISAs are mitigated.
249 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
250 restricted to 127: up to 127 FMAs (or other operation)
251 may be performed in total.
252 Also given that it is in-registers only at present some care has to be
253 taken on regfile resource utilisation. However it is perfectly possible
254 to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
255 the usual 6-level large Matrix Multiply, without the usual difficulties
256 associated with SIMD.
258 Also the `svshape` instruction only provides access to part of the
259 Matrix REMAP capability. Rotation and mirroring need to be done by
260 programming the SVSHAPE SPRs directly, which can take a lot more
261 instructions. Future versions of SVP64 will include EXT1xx prefixed
262 variants (`psvshape`) which provide more comprehensive capacity and
263 mitigate the need to write direct to the SVSHAPE SPRs.
265 ### FFT/DCT Triple Loop
267 DCT and FFT are some of the most astonishingly used algorithms in
268 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
269 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
272 An in-depth analysis showed that it is possible to do in-place in-register
273 DCT and FFT as long as twin-result "butterfly" instructions are provided.
274 These can be found in the [[openpower/isa/svfparith]] page if performing
275 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
276 integer operations would be required)*. These "butterfly" instructions
277 avoid the need for a temporary register because the two array positions
278 being overwritten will be "in-flight" in any In-Order or Out-of-Order
281 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
282 accept predicate masks. Given that it is common to perform recursive
283 convolutions combining smaller Power-2 DCT/FFT to create larger DCT/FFTs
284 in practice the RADIX2 limit is not a problem. A Bluestein convolution
285 to compute arbitrary length is demonstrated by
286 [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
290 The purpose of Indexing is to provide a generalised version of
291 Vector ISA "Permute" instructions, such as VSX `vperm`. The
292 Indexing is abstracted out and may be applied to much more
293 than an element move/copy, and is not limited for example
294 to the number of bytes that can fit into a VSX register.
295 Indexing may be applied to LD/ST (even on Indexed LD/ST
296 instructions such as `sv.lbzx`), arithmetic operations,
297 extsw: there is no artificial limit.
299 The only major caveat is that the registers to be used as
300 Indices must not be modified by any instruction after Indexed Mode
301 is established, and neither must MAXVL be altered. Additionally,
302 no register used as an Index may exceed MAXVL-1.
305 these conditions results in `UNDEFINED` behaviour.
306 These conditions allow a Read-After-Write (RAW) Hazard to be created on
307 the entire range of Indices to be subsequently used, but a corresponding
308 Write-After-Read Hazard by any instruction that modifies the Indices
309 **does not have to be created**. Given the large number of registers
310 involved in Indexing this is a huge resource saving and reduction
311 in micro-architectural complexity. MAXVL is likewise
312 included in the RAW Hazards because it is involved in calculating
313 how many registers are to be considered Indices.
315 With these Hazard Mitigations in place, high-performance implementations
316 may read-cache the Indices at the point where a given `svindex` instruction
317 is called (or SVSHAPE SPRs - and MAXVL - directly altered) by issuing
318 background GPR register file reads whilst other instructions are being
321 The original motivation for Indexed REMAP was to mitigate the need to add
322 an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
323 a stand-alone instruction. Usually a Vector ISA would add a non-conflicting
324 variant (as in VSX `vperm`) but it is common to need to permute by source,
325 with the risk of conflict, that has to be resolved, for example, in AVX-512
328 Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
329 destinations), which on a superficial analysis may be perceived to be a
330 problem, until it is recalled that, firstly, Simple-V is designed specifically
331 to require Program Order to be respected, and that Matrix, DCT and FFT
332 all *already* critically depend on overlapping Reads/Writes: Matrix
333 uses overlapping registers as accumulators. Thus the Register Hazard
334 Management needed by Indexed REMAP *has* to be in place anyway.
336 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
337 clearly that of the additional reading of the GPRs to be used as Indices,
338 plus the setup cost associated with creating those same Indices.
339 If any Deterministic REMAP can cover the required task, clearly it
340 is adviseable to use it instead.
342 *Programmer's note: some algorithms may require skipping of Indices exceeding
343 VL-1, not MAXVL-1. This may be achieved programmatically by performing
344 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
345 and RB contains the value of VL returned from `setvl`. The resultant
346 CR Fields may then be used as Predicate Masks to exclude those operations
347 with an Index exceeding VL-1.*
349 ### Parallel Reduction
351 Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
352 (Power ISA v3.0B) operation is leveraged, unmodified, to give the
353 *appearance* and *effect* of Reduction.
355 In Horizontal-First Mode, Vector-result reduction **requires**
356 the destination to be a Vector, which will be used to store
357 intermediary results.
359 Given that the tree-reduction schedule is deterministic,
360 Interrupts and exceptions
361 can therefore also be precise. The final result will be in the first
362 non-predicate-masked-out destination element, but due again to
363 the deterministic schedule programmers may find uses for the intermediate
366 When Rc=1 a corresponding Vector of co-resultant CRs is also
367 created. No special action is taken: the result *and its CR Field*
368 are stored "as usual" exactly as all other SVP64 Rc=1 operations.
370 Note that the Schedule only makes sense on top of certain instructions:
371 X-Form with a Register Profile of `RT,RA,RB` is fine because two sources
372 and the destination are all the same type. Like Scalar
373 Reduction, nothing is prohibited:
374 the results of execution on an unsuitable instruction may simply
375 not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
376 may be used, and whilst it is down to the Programmer to walk through the
377 process the Programmer can be confident that the Parallel-Reduction is
378 guaranteed 100% Deterministic.
380 Critical to note regarding use of Parallel-Reduction REMAP is that,
381 exactly as with all REMAP Modes, the `svshape` instruction *requests*
382 a certain Vector Length (number of elements to reduce) and then
383 sets VL and MAXVL at the number of **operations** needed to be
384 carried out. Thus, equally as importantly, like Matrix REMAP
385 the total number of operations
386 is restricted to 127. Any Parallel-Reduction requiring more operations
387 will need to be done manually in batches (hierarchical
388 recursive Reduction).
390 Also important to note is that the Deterministic Schedule is arranged
391 so that some implementations *may* parallelise it (as long as doing so
392 respects Program Order and Register Hazards). Performance (speed)
394 implementation is neither strictly defined or guaranteed. As with
395 the Vulkan(tm) Specification, strict compliance is paramount whilst
396 performance is at the discretion of Implementors.
398 **Parallel-Reduction with Predication**
400 To avoid breaking the strict RISC-paradigm, keeping the Issue-Schedule
401 completely separate from the actual element-level (scalar) operations,
402 Move operations are **not** included in the Schedule. This means that
403 the Schedule leaves the final (scalar) result in the first-non-masked
404 element of the Vector used. With the predicate mask being dynamic
405 (but deterministic) this result could be anywhere.
407 If that result is needed to be moved to a (single) scalar register
408 then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
409 needed to get it, where the predicate is the exact same predicate used
410 in the prior Parallel-Reduction instruction.
412 * If there was only a single
413 bit in the predicate then the result will not have moved or been altered
414 from the source vector prior to the Reduction
415 * If there was more than one bit the result will be in the
416 first element with a predicate bit set.
418 In either case the result is in the element with the first bit set in
421 Programmer's Note: For *some* hardware implementations
422 the vector-to-scalar copy may be a slow operation, as may the Predicated
423 Parallel Reduction itself.
424 It may be better to perform a pre-copy
425 of the values, compressing them (VREDUCE-style) into a contiguous block,
426 which will guarantee that the result goes into the very first element
427 of the destination vector, in which case clearly no follow-up
428 vector-to-scalar MV operation is needed.
432 The simplest usage is to perform an overwrite, specifying all three
433 register operands the same.
436 svshape parallelreduce, 6
440 The Reduction Schedule will issue the Parallel Tree Reduction spanning
441 registers 8 through 13, by adjusting the offsets to RT, RA and RB as
442 necessary (see "Parallel Reduction algorithm" in a later section).
444 A non-overwrite is possible as well but just as with the overwrite
445 version, only those destination elements necessary for storing
446 intermediary computations will be written to: the remaining elements
447 will **not** be overwritten and will **not** be zero'd.
450 svshape parallelreduce, 6
454 However it is critical to note that if the source and destination are
455 not the same then the trick of using a follow-up vector-scalar MV will
458 ### Sub-Vector Horizontal Reduction
460 To achieve Sub-Vector Horizontal Reduction, Pack/Unpack should be enabled,
461 which will turn the Schedule around such that issuing of the Scalar
462 Defined Words is done with SUBVL looping as the inner loop not the
463 outer loop. Rc=1 with Sub-Vectors (SUBVL=2,3,4) is `UNDEFINED` behaviour.
465 ## Determining Register Hazards
467 For high-performance (Multi-Issue, Out-of-Order) systems it is critical
468 to be able to statically determine the extent of Vectors in order to
469 allocate pre-emptive Hazard protection. The next task is to eliminate
470 masked-out elements using predicate bits, freeing up the associated
473 For non-REMAP situations `VL` is sufficient to ascertain early
474 Hazard coverage, and with SVSTATE being a high priority cached
475 quantity at the same level of MSR and PC this is not a problem.
477 The problems come when REMAP is enabled. Indexed REMAP must instead
478 use `MAXVL` as the earliest (simplest)
479 batch-level Hazard Reservation indicator (after taking element-width
480 overriding on the Index source into consideration),
481 but Matrix, FFT and Parallel Reduction must all use completely different
482 schemes. The reason is that VL is used to step through the total
483 number of *operations*, not the number of registers.
484 The "Saving Grace" is that all of the REMAP Schedules are 100% Deterministic.
486 Advance-notice Parallel computation and subsequent cacheing
487 of all of these complex Deterministic REMAP Schedules is
488 *strongly recommended*, thus allowing clear and precise multi-issue
489 batched Hazard coverage to be deployed, *even for Indexed Mode*.
490 This is only possible for Indexed due to the strict guidelines
491 given to Programmers.
493 In short, there exists solutions to the problem of Hazard Management,
494 with varying degrees of refinement possible at correspondingly
495 increasing levels of complexity in hardware.
497 A reminder: when Rc=1 each result register (element) has an associated
498 co-result CR Field (one per result element). Thus above when determining
499 the Write-Hazards for result registers the corresponding Write-Hazards for the
500 corresponding associated co-result CR Field must not be forgotten, *including* when
503 ## REMAP area of SVSTATE SPR
505 The following bits of the SVSTATE SPR are used for REMAP:
507 |32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
508 | -- | -- | -- | -- | -- | ----- | ------ |
509 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
511 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
512 mi0-2 apply to RA, RB, RC respectively, as input registers, and
513 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
514 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
515 SVSHAPE is actively applied or not.
517 * bit 0 of SVme indicates if mi0 is applied to RA / FRA / BA / BFA
518 * bit 1 of SVme indicates if mi1 is applied to RB / FRB / BB
519 * bit 2 of SVme indicates if mi2 is applied to RC / FRC / BC
520 * bit 3 of SVme indicates if mo0 is applied to RT / FRT / BT / BF
521 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
522 (LD/ST-with-update has an implicit 2nd write register, RA)
524 The "persistence" bit if set will result in all Active REMAPs being applied
531 # svremap instruction <a name="svremap"> </a>
535 svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
537 |0 |6 |11 |13 |15 |17 |19 |21 | 22.25 |26..31 |
538 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
539 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
543 * svremap SVme,mi0,mi1,mi2,mo0,mo1,pst
548 # registers RA RB RC RT EA/FRS SVSHAPE0-3 indices
549 SVSTATE[32:33] <- mi0
550 SVSTATE[34:35] <- mi1
551 SVSTATE[36:37] <- mi2
552 SVSTATE[38:39] <- mo0
553 SVSTATE[40:41] <- mo1
554 # enable bit for RA RB RC RT EA/FRS
555 SVSTATE[42:46] <- SVme
556 # persistence bit (applies to more than one instruction)
560 Special Registers Altered:
566 `svremap` determines the relationship between registers and SVSHAPE SPRs.
567 The bitmask `SVme` determines which registers have a REMAP applied, and mi0-mo1
568 determine which shape is applied to an activated register. the `pst` bit if
569 cleared indicated that the REMAP operation shall only apply to the immediately-following
570 instruction. If set then REMAP remains permanently enabled until such time as it is
571 explicitly disabled, either by `setvl` setting a new MAXVL, or with another
572 `svremap` instruction. `svindex` and `svshape2` are also capable of setting or
573 clearing persistence, as well as partially covering a subset of the capability of
574 `svremap` to set register-to-SVSHAPE relationships.
576 Programmer's Note: applying non-persistent `svremap` to an instruction that has
577 no REMAP enabled or is a Scalar operation will obviously have no effect but
578 the bits 32 to 46 will at least have been set in SVSTATE. This may prove useful
579 when using `svindex` or `svshape2`.
581 Hardware Architectural Note: when persistence is not set it is critically important
582 to treat the `svremap` and the following SVP64 instruction as an indivisible fused operation.
583 *No state* is stored in the SVSTATE SPR in order to allow continuation should an
584 Interrupt occur between the two instructions. Thus, Interrupts must be prohibited
585 from occurring or other workaround deployed. When persistence is set this issue
588 It is critical to note that if persistence is clear `svremap` is the **only** way
589 to activate REMAP on any given (following) instruction. If persistence is set however then
590 **all** SVP64 instructions go through REMAP as long as `SVme` is non-zero.
596 # SHAPE Remapping SPRs
598 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
599 which have the same format.
601 Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
602 disabled: the register's elements are a linear (1D) vector.
604 |31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
605 |---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
606 |0b00 |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
607 |0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
608 |0b01 |submode|offset| invxyz | submode2| zdimsz |mode |xdimsz|DCT/FFT|
609 |0b10 |submode|offset| invxyz | rsvd | rsvd |rsvd |xdimsz|Preduce|
610 |0b11 | | | | | | | |rsvd |
612 mode sets different behaviours (straight matrix multiply, FFT, DCT).
614 * **mode=0b00** sets straight Matrix Mode
615 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
616 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
617 * **mode=0b10** sets "Parallel Reduction" Schedules.
619 ## Parallel Reduction Mode
621 Creates the Schedules for Parallel Tree Reduction.
623 * **submode=0b00** selects the left operand index
624 * **submode=0b01** selects the right operand index
626 * When bit 0 of `invxyz` is set, the order of the indices
627 in the inner for-loop are reversed. This has the side-effect
628 of placing the final reduced result in the last-predicated element.
629 It also has the indirect side-effect of swapping the source
630 registers: Left-operand index numbers will always exceed
631 Right-operand indices.
632 When clear, the reduced result will be in the first-predicated
633 element, and Left-operand indices will always be *less* than
635 * When bit 1 of `invxyz` is set, the order of the outer loop
636 step is inverted: stepping begins at the nearest power-of two
637 to half of the vector length and reduces by half each time.
638 When clear the step will begin at 2 and double on each
643 submode2=0 is for FFT. For FFT submode the following schedules may be
646 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
648 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
650 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
652 When submode2 is 1 or 2, for DCT inner butterfly submode the following
653 schedules may be selected. When submode2 is 1, additional bit-reversing
656 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
658 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
659 in reverse-order, in-place
660 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
661 useful for calculating the cosine coefficient
662 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
663 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
665 When submode2 is 3 or 4, for DCT outer butterfly submode the following
666 schedules may be selected. When submode is 3, additional bit-reversing
669 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
670 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
672 `zdimsz` is used as an in-place "Stride", particularly useful for
673 column-based in-place DCT/FFT.
677 In Matrix Mode, skip allows dimensions to be skipped from being included
678 in the resultant output index. this allows sequences to be repeated:
679 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
680 modulo ```0 1 2 0 1 2 ...```
682 * **skip=0b00** indicates no dimensions to be skipped
683 * **skip=0b01** sets "skip 1st dimension"
684 * **skip=0b10** sets "skip 2nd dimension"
685 * **skip=0b11** sets "skip 3rd dimension"
687 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
688 zero then x-dimensional counting begins from 0 and increments, otherwise
689 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
691 offset will have the effect of offsetting the result by ```offset``` elements:
695 GPR(RT + remap(i) + SVSHAPE.offset) = ....
698 this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
699 bear in mind that unlike a static compiler SVSHAPE.offset may
700 be set dynamically at runtime.
702 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
703 that the array dimensionality for that dimension is 1. any dimension
704 not intended to be used must have its value set to 0 (dimensionality
705 of 1). A value of xdimsz=2 would indicate that in the first dimension
706 there are 3 elements in the array. For example, to create a 2D array
707 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
709 The format of the array is therefore as follows:
712 array[xdimsz+1][ydimsz+1][zdimsz+1]
715 However whilst illustrative of the dimensionality, that does not take the
716 "permute" setting into account. "permute" may be any one of six values
717 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
718 below shows how the permutation dimensionality order works:
720 | permute | order | array format |
721 | ------- | ----- | ------------------------ |
722 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
723 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
724 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
725 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
726 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
727 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
728 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
729 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
731 In other words, the "permute" option changes the order in which
732 nested for-loops over the array would be done. See executable
733 python reference code for further details.
735 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
738 With all these options it is possible to support in-place transpose,
739 in-place rotate, Matrix Multiply and Convolutions, without being
740 limited to Power-of-Two dimension sizes.
744 Indexed Mode activates reading of the element indices from the GPR
745 and includes optional limited 2D reordering.
746 In its simplest form (without elwidth overrides or other modes):
750 return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
753 element_result = ....
754 GPR(RT + indexed_remap(i)) = element_result
757 With element-width overrides included, and using the pseudocode
758 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
763 svreg = SVSHAPE.SVGPR << 1
764 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
765 offs = SVSHAPE.offset
766 return get_polymorphed_reg(svreg, srcwid, i) + offs
769 element_result = ....
770 rt_idx = indexed_remap(i)
771 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
774 Matrix-style reordering still applies to the indices, except limited
775 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
776 (Y,X) for in-place Transposition.
777 Only one dimension may optionally be skipped. Inversion of either
778 X or Y or both is possible (2D mirroring). Pseudocode for Indexed Mode (including elwidth
779 overrides) may be written in terms of Matrix Mode, specifically
780 purposed to ensure that the 3rd dimension (Z) has no effect:
783 def index_remap(ISHAPE, i):
784 MSHAPE.skip = 0b0 || ISHAPE.sk1
785 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
786 MSHAPE.xdimsz = ISHAPE.xdimsz
787 MSHAPE.ydimsz = ISHAPE.ydimsz
788 MSHAPE.zdimsz = 0 # disabled
789 if ISHAPE.permute = 0b110 # 0,1
790 MSHAPE.permute = 0b000 # 0,1,2
791 if ISHAPE.permute = 0b111 # 1,0
792 MSHAPE.permute = 0b010 # 1,0,2
793 el_idx = remap_matrix(MSHAPE, i)
794 svreg = ISHAPE.SVGPR << 1
795 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
797 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
800 The most important observation above is that the Matrix-style
801 remapping occurs first and the Index lookup second. Thus it
802 becomes possible to perform in-place Transpose of Indices which
803 may have been costly to set up or costly to duplicate
804 (waste register file space).
810 # svshape instruction <a name="svshape"> </a>
812 Form: SVM-Form SV "Matrix" Form (see [[isatables/fields.text]])
814 svshape SVxd,SVyd,SVzd,SVRM,vf
816 | 0.5|6.10 |11.15 |16..20 | 21..24 | 25 | 26..31| name |
817 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
818 |OPCD| SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
821 # for convenience, VL to be calculated and stored in SVSTATE
823 mscale[0:5] <- 0b000001 # for scaling MAXVL
824 itercount[0:6] <- [0] * 7
825 SVSTATE[0:31] <- [0] * 32
826 # only overwrite REMAP if "persistence" is zero
827 if (SVSTATE[62] = 0b0) then
828 SVSTATE[32:33] <- 0b00
829 SVSTATE[34:35] <- 0b00
830 SVSTATE[36:37] <- 0b00
831 SVSTATE[38:39] <- 0b00
832 SVSTATE[40:41] <- 0b00
833 SVSTATE[42:46] <- 0b00000
836 # clear out all SVSHAPEs
837 SVSHAPE0[0:31] <- [0] * 32
838 SVSHAPE1[0:31] <- [0] * 32
839 SVSHAPE2[0:31] <- [0] * 32
840 SVSHAPE3[0:31] <- [0] * 32
842 # set schedule up for multiply
843 if (SVrm = 0b0000) then
844 # VL in Matrix Multiply is xd*yd*zd
845 xd <- (0b00 || SVxd) + 1
846 yd <- (0b00 || SVyd) + 1
847 zd <- (0b00 || SVzd) + 1
849 vlen[0:6] <- n[14:20]
850 # set up template in SVSHAPE0, then copy to 1-3
851 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
852 SVSHAPE0[6:11] <- (0b0 || SVyd) # ydim
853 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim
854 SVSHAPE0[28:29] <- 0b11 # skip z
856 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
857 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
858 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
860 SVSHAPE1[18:20] <- 0b001 # permute x,z,y
861 SVSHAPE1[28:29] <- 0b01 # skip z
863 SVSHAPE2[18:20] <- 0b001 # permute x,z,y
864 SVSHAPE2[28:29] <- 0b11 # skip y
866 # set schedule up for FFT butterfly
867 if (SVrm = 0b0001) then
868 # calculate O(N log2 N)
871 if SVxd[4-n] = 0 then
874 n <- ((0b0 || SVxd) + 1) * n
876 # set up template in SVSHAPE0, then copy to 1-3
878 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
879 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D FFT)
880 mscale <- (0b0 || SVzd) + 1
881 SVSHAPE0[30:31] <- 0b01 # Butterfly mode
883 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
884 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
886 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
888 SVSHAPE2[28:29] <- 0b10 # k schedule
890 # set schedule up for (i)DCT Inner butterfly
891 # SVrm Mode 2 (Mode 6 for iDCT) is for pre-calculated coefficients,
892 # SVrm Mode 4 (Mode 12 for iDCT) is for on-the-fly (Vertical-First Mode)
893 if ((SVrm = 0b0010) | (SVrm = 0b0100) |
894 (SVrm = 0b1010) | (SVrm = 0b1100)) then
895 # calculate O(N log2 N)
898 if SVxd[4-n] = 0 then
901 n <- ((0b0 || SVxd) + 1) * n
903 # set up template in SVSHAPE0, then copy to 1-3
905 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
906 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
907 mscale <- (0b0 || SVzd) + 1
908 if (SVrm = 0b1011) then
909 SVSHAPE0[30:31] <- 0b11 # iDCT mode
910 SVSHAPE0[18:20] <- 0b011 # iDCT Outer Butterfly sub-mode
911 SVSHAPE0[21:23] <- 0b101 # "inverse" on outer and inner loop
913 SVSHAPE0[30:31] <- 0b01 # DCT mode
914 SVSHAPE0[18:20] <- 0b100 # DCT Outer Butterfly sub-mode
915 SVSHAPE0[6:11] <- 0b000010 # DCT Butterfly mode
917 SVSHAPE1[0:31] <- SVSHAPE0[0:31] # j+halfstep schedule
918 SVSHAPE2[0:31] <- SVSHAPE0[0:31] # costable coefficients
920 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
921 # reset costable "striding" to 1
922 SVSHAPE2[12:17] <- 0b000000
924 # set schedule up for DCT COS table generation
925 if (SVrm = 0b0101) | (SVrm = 0b1101) then
926 # calculate O(N log2 N)
928 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
929 itercount[0:6] <- (0b0 || itercount[0:5])
932 if SVxd[4-n] = 0 then
935 vlen[0:6] <- vlen + itercount
936 itercount[0:6] <- (0b0 || itercount[0:5])
937 # set up template in SVSHAPE0, then copy to 1-3
939 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
940 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
941 mscale <- (0b0 || SVzd) + 1
942 SVSHAPE0[30:31] <- 0b01 # DCT/FFT mode
943 SVSHAPE0[6:11] <- 0b000100 # DCT Inner Butterfly COS-gen mode
944 if (SVrm = 0b0101) then
945 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop for DCT
947 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
948 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
949 # for cos coefficient
950 SVSHAPE1[28:29] <- 0b10 # ci schedule
951 SVSHAPE2[28:29] <- 0b11 # size schedule
953 # set schedule up for iDCT / DCT inverse of half-swapped ordering
954 if (SVrm = 0b0110) | (SVrm = 0b1110) | (SVrm = 0b1111) then
955 vlen[0:6] <- (0b00 || SVxd) + 0b0000001
956 # set up template in SVSHAPE0
957 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
958 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
959 mscale <- (0b0 || SVzd) + 1
960 if (SVrm = 0b1110) then
961 SVSHAPE0[18:20] <- 0b001 # DCT opposite half-swap
962 if (SVrm = 0b1111) then
963 SVSHAPE0[30:31] <- 0b01 # FFT mode
965 SVSHAPE0[30:31] <- 0b11 # DCT mode
966 SVSHAPE0[6:11] <- 0b000101 # DCT "half-swap" mode
968 # set schedule up for parallel reduction
969 if (SVrm = 0b0111) then
970 # calculate the total number of operations (brute-force)
972 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
973 step[0:6] <- 0b0000001
975 do while step <u itercount
976 newstep <- step[1:6] || 0b0
978 do while (j+step <u itercount)
982 # VL in Parallel-Reduce is the number of operations
984 # set up template in SVSHAPE0, then copy to 1. only 2 needed
985 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
986 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
987 mscale <- (0b0 || SVzd) + 1
988 SVSHAPE0[30:31] <- 0b10 # parallel reduce submode
990 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
991 # set up right operand (left operand 28:29 is zero)
992 SVSHAPE1[28:29] <- 0b01 # right operand
994 # set VL, MVL and Vertical-First
995 m[0:12] <- vlen * mscale
996 maxvl[0:6] <- m[6:12]
997 SVSTATE[0:6] <- maxvl # MAVXL
998 SVSTATE[7:13] <- vlen # VL
1002 Special Registers Altered:
1008 `svshape` is a convenience instruction that reduces instruction
1009 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
1010 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
1011 including VL and MAXVL. Using `svshape` therefore does not also
1016 * **SVxd** - SV REMAP "xdim"
1017 * **SVyd** - SV REMAP "ydim"
1018 * **SVzd** - SV REMAP "zdim"
1019 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
1020 * **vf** - sets "Vertical-First" mode
1022 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
1023 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
1025 There are 14 REMAP Modes (2 Modes are RESERVED for `svshape2`)
1027 | SVRM | Remap Mode description |
1029 | 0b0000 | Matrix 1/2/3D |
1030 | 0b0001 | FFT Butterfly |
1031 | 0b0010 | DCT Inner butterfly, pre-calculated coefficients |
1032 | 0b0011 | DCT Outer butterfly |
1033 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1034 | 0b0101 | DCT COS table index generation |
1035 | 0b0110 | DCT half-swap |
1036 | 0b0111 | Parallel Reduction |
1037 | 0b1000 | reserved for svshape2 |
1038 | 0b1001 | reserved for svshape2 |
1039 | 0b1010 | iDCT Inner butterfly, pre-calculated coefficients |
1040 | 0b1011 | iDCT Outer butterfly |
1041 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1042 | 0b1101 | iDCT COS table index generation |
1043 | 0b1110 | iDCT half-swap |
1044 | 0b1111 | FFT half-swap |
1046 Examples showing how all of these Modes operate exists in the online
1047 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD). Explaining
1048 these Modes further in detail is beyond the scope of this document.
1050 In Indexed Mode, there are only 5 bits available to specify the GPR
1051 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
1052 5 bits are given in the `SVxd` field: the bottom two implicit bits
1053 will be zero (`SVxd || 0b00`).
1055 `svshape` has *limited applicability* due to being a 32-bit instruction.
1056 The full capability of SVSHAPE SPRs may be accessed by directly writing
1057 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
1058 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
1059 instruction, `psvshape`, may extend the capability here.
1061 *Architectural Resource Allocation note: the SVRM field is carefully
1062 crafted to allocate two Modes, corresponding to bits 21-23 within the
1063 instruction being set to the value `0b100`, to `svshape2` (not
1064 `svshape`). These two Modes are
1065 considered "RESERVED" within the context of `svshape` but it is
1066 absolutely critical to allocate the exact same pattern in XO for
1067 both instructions in bits 26-31.*
1074 # svindex instruction <a name="svindex"> </a>
1078 | 0.5|6.10 |11.15 |16.20 | 21..25 | 26..31| name | Form |
1079 | -- | -- | --- | ---- | ----------- | ------| -------- | ---- |
1080 |OPCD| SVG | rmm | SVd | ew/yx/mm/sk | XO | svindex | SVI-Form |
1082 * svindex SVG,rmm,SVd,ew,SVyx,mm,sk
1087 # based on nearest MAXVL compute other dimension
1091 do while d*dim <u ([0]*4 || MVL)
1094 # set up template, then copy once location identified
1096 shape[30:31] <- 0b00 # mode
1098 shape[18:20] <- 0b110 # indexed xd/yd
1099 shape[0:5] <- (0b0 || SVd) # xdim
1100 if sk = 0 then shape[6:11] <- 0 # ydim
1101 else shape[6:11] <- 0b111111 # ydim max
1103 shape[18:20] <- 0b111 # indexed yd/xd
1104 if sk = 1 then shape[6:11] <- 0 # ydim
1105 else shape[6:11] <- d-1 # ydim max
1106 shape[0:5] <- (0b0 || SVd) # ydim
1107 shape[12:17] <- (0b0 || SVG) # SVGPR
1108 shape[28:29] <- ew # element-width override
1109 shape[21] <- sk # skip 1st dimension
1111 # select the mode for updating SVSHAPEs
1112 SVSTATE[62] <- mm # set or clear persistence
1114 # clear out all SVSHAPEs first
1115 SVSHAPE0[0:31] <- [0] * 32
1116 SVSHAPE1[0:31] <- [0] * 32
1117 SVSHAPE2[0:31] <- [0] * 32
1118 SVSHAPE3[0:31] <- [0] * 32
1119 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1120 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1124 # activate requested shape
1125 if idx = 0 then SVSHAPE0 <- shape
1126 if idx = 1 then SVSHAPE1 <- shape
1127 if idx = 2 then SVSHAPE2 <- shape
1128 if idx = 3 then SVSHAPE3 <- shape
1129 SVSTATE[bit*2+32:bit*2+33] <- idx
1130 # increment shape index, modulo 4
1131 if idx = 3 then idx <- 0
1134 # refined SVSHAPE/REMAP update mode
1137 if idx = 0 then SVSHAPE0 <- shape
1138 if idx = 1 then SVSHAPE1 <- shape
1139 if idx = 2 then SVSHAPE2 <- shape
1140 if idx = 3 then SVSHAPE3 <- shape
1141 SVSTATE[bit*2+32:bit*2+33] <- idx
1142 SVSTATE[46-bit] <- 1
1145 Special Registers Altered:
1151 `svindex` is a convenience instruction that reduces instruction
1152 count for Indexed REMAP Mode. It sets up
1153 (overwrites) all required SVSHAPE SPRs and can modify the REMAP
1154 area of the SVSTATE SPR as well. The relevant SPRs *may* be directly programmed with
1155 `mtspr` however it is laborious to do so: svindex saves instructions
1156 covering much of Indexed REMAP capability.
1160 * **SVd** - SV REMAP x/y dim
1161 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
1163 * **ew** - sets element width override on the Indices
1164 * **SVG** - GPR SVG<<2 to be used for Indexing
1165 * **yx** - 2D reordering to be used if yx=1
1166 * **mm** - mask mode. determines how `rmm` is interpreted.
1167 * **sk** - Dimension skipping enabled
1169 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
1170 "off-by-one". In the assembler
1171 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
1173 *Note: when `yx=1,sk=0` the second dimension is calculated as
1178 * `rmm`, like REMAP.SVme, has bit 0
1179 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
1180 bit 3 to mo0 and bit 4 to mi1
1181 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
1182 * for each bit set in the 5-bit `rmm`, in order, the first
1183 as-yet-unset SVSHAPE will be updated
1184 with the other operands in the instruction, and the REMAP
1186 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
1187 * SVSTATE persistence bit is cleared
1188 * No other alterations to SVSTATE are carried out
1190 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
1191 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
1192 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
1193 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
1195 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
1196 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
1197 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
1199 Rough algorithmic form:
1202 marray = [mi0, mi1, mi2, mo0, mo1]
1205 if not rmm[bit]: continue
1207 SVSTATE{marray[bit]} = idx
1208 idx = (idx+1) modulo 4
1213 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
1214 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
1216 * only the selected SVSHAPE is overwritten
1217 * only the relevant bits in the REMAP area of SVSTATE are updated
1218 * REMAP persistence bit is set.
1220 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
1221 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
1222 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
1223 set to 2 (SVSHAPE2).
1225 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
1226 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
1227 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
1228 set to 3 (SVSHAPE3).
1230 Rough algorithmic form:
1233 marray = [mi0, mi1, mi2, mo0, mo1]
1237 SVSTATE{marray[bit]} = idx
1241 In essence, `mm=0` is intended for use to set as much of the
1242 REMAP State SPRs as practical with a single instruction,
1243 whilst `mm=1` is intended to be a little more refined.
1245 **Usage guidelines**
1247 * **Disable 2D mapping**: to only perform Indexing without
1248 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
1250 * **Modulo 1D mapping**: to perform Indexing cycling through the
1251 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
1252 no requirement to set VL equal to a multiple of N.
1253 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
1254 `xdim=M,ydim=CEIL(MAXVL/M)`.
1256 Beyond these mappings it becomes necessary to write directly to
1257 the SVSTATE SPRs manually.
1264 # svshape2 (offset-priority) <a name="svshape2"> </a>
1268 | 0-5|6-9 |10|11-15 |16-20 | 21-24 | 25 | 26-31 | Form |
1269 | -- |----|--| --- | ----- | ------ | -- | ------| -------- |
1270 | PO |offs|yx| rmm | SVd | 100/mm | sk | XO | SVM2-Form |
1272 * svshape2 offs,yx,rmm,SVd,sk,mm
1277 # based on nearest MAXVL compute other dimension
1281 do while d*dim <u ([0]*4 || MVL)
1283 # set up template, then copy once location identified
1285 shape[30:31] <- 0b00 # mode
1286 shape[0:5] <- (0b0 || SVd) # x/ydim
1288 shape[18:20] <- 0b000 # ordering xd/yd(/zd)
1289 if sk = 0 then shape[6:11] <- 0 # ydim
1290 else shape[6:11] <- 0b111111 # ydim max
1292 shape[18:20] <- 0b010 # ordering yd/xd(/zd)
1293 if sk = 1 then shape[6:11] <- 0 # ydim
1294 else shape[6:11] <- d-1 # ydim max
1295 # offset (the prime purpose of this instruction)
1296 shape[24:27] <- SVo # offset
1297 if sk = 1 then shape[28:29] <- 0b01 # skip 1st dimension
1298 else shape[28:29] <- 0b00 # no skipping
1299 # select the mode for updating SVSHAPEs
1300 SVSTATE[62] <- mm # set or clear persistence
1302 # clear out all SVSHAPEs first
1303 SVSHAPE0[0:31] <- [0] * 32
1304 SVSHAPE1[0:31] <- [0] * 32
1305 SVSHAPE2[0:31] <- [0] * 32
1306 SVSHAPE3[0:31] <- [0] * 32
1307 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1308 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1312 # activate requested shape
1313 if idx = 0 then SVSHAPE0 <- shape
1314 if idx = 1 then SVSHAPE1 <- shape
1315 if idx = 2 then SVSHAPE2 <- shape
1316 if idx = 3 then SVSHAPE3 <- shape
1317 SVSTATE[bit*2+32:bit*2+33] <- idx
1318 # increment shape index, modulo 4
1319 if idx = 3 then idx <- 0
1322 # refined SVSHAPE/REMAP update mode
1325 if idx = 0 then SVSHAPE0 <- shape
1326 if idx = 1 then SVSHAPE1 <- shape
1327 if idx = 2 then SVSHAPE2 <- shape
1328 if idx = 3 then SVSHAPE3 <- shape
1329 SVSTATE[bit*2+32:bit*2+33] <- idx
1330 SVSTATE[46-bit] <- 1
1333 Special Registers Altered:
1339 `svshape2` is an additional convenience instruction that prioritises
1340 setting `SVSHAPE.offset`. Its primary purpose is for use when
1341 element-width overrides are used. It has identical capabilities to `svindex` and
1342 in terms of both options (skip, etc.) and ability to activate REMAP
1343 (rmm, mask mode) but unlike `svindex` it does not set GPR REMAP,
1344 only a 1D or 2D `svshape`, and
1345 unlike `svshape` it can set an arbirrary `SVSHAPE.offset` immediate.
1347 One of the limitations of Simple-V is that Vector elements start on the boundary
1348 of the Scalar regfile, which is fine when element-width overrides are not
1349 needed. If the starting point of a Vector with smaller elwidths must begin
1350 in the middle of a register, normally there would be no way to do so except
1351 through LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`is
1356 * **offs** (4 bits) - unsigned offset
1357 * **yx** (1 bit) - swap XY to YX
1358 * **SVd** dimension size
1359 * **rmm** REMAP mask
1361 * **sk** (1 bit) skips 1st dimension if set
1363 Dimensions are calculated exactly as `svindex`. `rmm` and
1364 `mm` are as per `svindex`.
1366 *Programmer's Note: offsets for `svshape2` may be specified in the range
1367 0-15. Given that the principle of Simple-V is to fit on top of
1368 byte-addressable register files and that GPR and FPR are 64-bit (8 bytes)
1369 it should be clear that the offset may, when `elwidth=8`, begin an
1370 element-level operation starting element zero at any arbitrary byte.
1371 On cursory examination attempting to go beyond the range 0-7 seems
1372 unnecessary given that the **next GPR or FPR** is an
1373 alias for an offset in the range 8-15. Thus by simply increasing
1374 the starting Vector point of the operation to the next register it
1375 can be seen that the offset of 0-7 would be sufficient. Unfortunately
1376 however some operations are EXTRA2-encoded it is **not possible**
1377 to increase the GPR/FPR register number by one, because EXTRA2-encoding
1378 of GPR/FPR Vector numbers are restricted to even numbering.
1379 For CR Fields the EXTRA2 encoding is even more sparse.
1380 The additional offset range (8-15) helps overcome these limitations.*
1382 *Hardware Implementor's note: with the offsets only being immediates
1383 and with register numbering being entirely immediate as well it is
1384 possible to correctly compute Register Hazards without requiring
1385 reading the contents of any SPRs. If however there are
1386 instructions that have directly written to the SVSTATE or SVSHAPE
1387 SPRs and those instructions are still in-flight then this position
1388 is clearly **invalid**. This is why Programmers are strongly
1389 discouraged from directly writing to these SPRs.*
1391 *Architectural Resource Allocation note: this instruction shares
1392 the space of `svshape`. Therefore it is critical that the two
1393 instructions, `svshape` and `svshape2` have the exact same XO
1394 in bits 26 thru 31. It is also critical that for `svshape2`,
1395 bit 21 of XO is a 1, bit 22 of XO is a 0, and bit 23 of XO is a 0.*
1403 Add `SVI, SVM, SVRM` to `XO (26:31)` Field in Book I, 1.6.2
1405 Add the following to Book I, 1.6.1, SVI-Form
1408 |0 |6 |11 |16 |21 |23 |24|25|26 31|
1409 | PO | SVG|rmm | SVd |ew |SVyx|mm|sk| XO |
1412 Add the following to Book I, 1.6.1, SVM-Form
1415 |0 |6 |11 |16 |21 |25 |26 |31 |
1416 | PO | SVxd | SVyd | SVzd | SVrm |vf | XO |
1419 Add the following to Book I, 1.6.1, SVM2-Form
1422 |0 |6 |10 |11 |16 |21 |24|25 |26 |31 |
1423 | PO | SVo |SVyx| rmm | SVd |XO |mm|sk | XO |
1426 Add the following to Book I, 1.6.1, SVRM-Form
1429 |0 |6 |11 |13 |15 |17 |19 |21 |22 |26 |31 |
1430 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 |pst |/// | XO |
1433 Add the following to Book I, 1.6.2
1437 Field used in REMAP to select the SVSHAPE for 1st input register
1440 Field used in REMAP to select the SVSHAPE for 2nd input register
1443 Field used in REMAP to select the SVSHAPE for 3rd input register
1446 Field used to specify the meaning of the rmm field for SVI-Form
1450 Field used in REMAP to select the SVSHAPE for 1st output register
1453 Field used in REMAP to select the SVSHAPE for 2nd output register
1456 Field used in REMAP to indicate "persistence" mode (REMAP
1457 continues to apply to multiple instructions)
1460 REMAP Mode field for SVI-Form and SVM2-Form
1463 Field used to specify dimensional skipping in svindex
1466 Immediate field used to specify the size of the REMAP dimension
1467 in the svindex and svshape2 instructions
1470 Immediate field used to specify a 9-bit signed
1471 two's complement integer which is concatenated
1472 on the right with 0b00 and sign-extended to 64 bits.
1475 Field used to specify a GPR to be used as a
1476 source for indexing.
1479 Simple-V immediate field for setting VL or MVL
1482 Simple-V "REMAP" map-enable bits (0-4)
1485 Field used by the svshape2 instruction as an offset
1488 Simple-V "REMAP" Mode
1491 Simple-V "REMAP" x-dimension size
1494 Simple-V "REMAP" y-dimension size
1497 Simple-V "REMAP" z-dimension size
1500 Extended opcode field. Note that bit 21 must be 1, 22 and 23
1501 must be zero, and bits 26-31 must be exactly the same as
1508 Appendix E Power ISA sorted by opcode
1509 Appendix F Power ISA sorted by version
1510 Appendix G Power ISA sorted by Compliancy Subset
1511 Appendix H Power ISA sorted by mnemonic
1513 | Form | Book | Page | Version | mnemonic | Description |
1514 |------|------|------|---------|----------|-------------|
1515 | SVRM | I | # | 3.0B | svremap | REMAP enabling instruction |
1516 | SVM | I | # | 3.0B | svshape | REMAP shape instruction |
1517 | SVM2 | I | # | 3.0B | svshape2 | REMAP shape instruction (2) |
1518 | SVI | I | # | 3.0B | svindex | REMAP General-purpose Indexing |