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.
95 REMAP allows the usual sequential vector loop `0..VL-1` to be "reshaped" (re-mapped)
96 from a linear form to a 2D or 3D transposed form, or "offset" to permit
97 arbitrary access to elements (when elwidth overrides are used),
98 independently on each Vector src or dest
99 register. Aside from Indexed REMAP this is entirely Hardware-accelerated
100 reordering and consequently not costly in terms of register access. It
101 will however place a burden on Multi-Issue systems but no more than if
102 the equivalent Scalar instructions were explicitly
103 loop-unrolled without SVP64, and some advanced implementations may even find
104 the Deterministic nature of the Scheduling to be easier on resources.
106 The initial primary motivation of REMAP was for Matrix Multiplication, reordering
107 of sequential data in-place: in-place DCT and FFT were easily justified given the
108 exceptionally high usage in Computer Science.
109 Four SPRs are provided which may be applied to any GPR, FPR or CR Field
110 so that for example a single FMAC may be
111 used in a single hardware-controlled 100% Deterministic loop to
112 perform 5x3 times 3x4 Matrix multiplication,
113 generating 60 FMACs *without needing explicit assembler unrolling*.
114 Additional uses include regular "Structure Packing"
115 such as RGB pixel data extraction and reforming.
117 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
118 Vector ISAs which would typically only have a limited set of instructions
119 that can be structure-packed (LD/ST typically), REMAP may be applied to
120 literally any instruction: CRs, Arithmetic, Logical, LD/ST, anything.
122 Note that REMAP does not *directly* apply to sub-vector elements but
123 only to the group: that
124 is what swizzle is for. Swizzle *can* however be applied to the same
125 instruction as REMAP. As explained in [[sv/mv.swizzle]]
126 and the [[svp64/appendix]], Pack and Unpack EXTRA Mode bits
127 can extend down into Sub-vector elements to perform vec2/vec3/vec4
128 sequential reordering, but even here, REMAP is not *individually*
129 extended down to the actual sub-vector elements themselves.
131 In its general form, REMAP is quite expensive to set up, and on some
132 implementations may introduce
133 latency, so should realistically be used only where it is worthwhile.
134 Given that even with latency the fact that up to 127 operations
135 can be requested to be issued (from a single instruction) it should
136 be clear that REMAP should not be dismissed for *possible* latency alone.
137 Commonly-used patterns such as Matrix Multiply, DCT and FFT have
138 helper instruction options which make REMAP easier to use.
140 There are four types of REMAP:
142 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
143 Matrix transpose and rotate. The Shapes are set up for an "Outer Product"
145 * **FFT/DCT**, with full triple-loop in-place support: limited to
147 * **Indexing**, for any general-purpose reordering, also includes
148 limited 2D reshaping.
149 * **Parallel Reduction**, for scheduling a sequence of operations
150 in a Deterministic fashion, in a way that may be parallelised,
151 to reduce a Vector down to a single value.
153 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
154 REMAP Schedules are 100% Deterministic **including Indexing** and are
155 designed to be incorporated in between the Decode and Issue phases,
156 directly into Register Hazard Management.
158 Parallel Reduction is unusual in that it requires a full vector array
159 of results (not a scalar) and uses the rest of the result Vector for
160 the purposes of storing intermediary calculations. As these intermediary
161 results are Deterministically computed they may be useful.
162 Additionally, because the intermediate results are always written out
163 it is possible to service Precise Interrupts without affecting latency
164 (a common limitation of Vector ISAs implementing explicit
165 Parallel Reduction instructions).
169 * normal vector element read/write of operands would be sequential
171 * this is not appropriate for (e.g.) Matrix multiply which requires
172 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
173 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
174 with this. both are expensive (copy large vectors, spill through memory)
175 and very few Packed SIMD ISAs cope with non-Power-2.
176 * REMAP **redefines** the order of access according to set
177 (Deterministic) "Schedules".
178 * The Schedules are not at all restricted to power-of-two boundaries
179 making it unnecessary to have for example specialised 3x4 transpose
180 instructions of other Vector ISAs.
182 Only the most commonly-used algorithms in computer science have REMAP
183 support, due to the high cost in both the ISA and in hardware. For
184 arbitrary remapping the `Indexed` REMAP may be used.
188 * `svshape` to set the type of reordering to be applied to an
189 otherwise usual `0..VL-1` hardware for-loop
190 * `svremap` to set which registers a given reordering is to apply to
192 * `sv.{instruction}` where any Vectorised register marked by `svremap`
193 will have its ordering REMAPPED according to the schedule set
196 The following illustrative example multiplies a 3x4 and a 5x3
201 svshape 5, 4, 3, 0, 0
202 svremap 15, 1, 2, 3, 0, 0, 0, 0
203 sv.fmadds *0, *8, *16, *0
206 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
207 * svremap activates four out of five registers RA RB RC RT RS (15)
213 - RS Remapping to not be activated
214 * sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
215 * With REMAP being active each register's element index is
216 *independently* transformed using the specified SHAPEs.
218 Thus the Vector Loop is arranged such that the use of
219 the multiply-and-accumulate instruction executes precisely the required
220 Schedule to perform an in-place in-registers Matrix Multiply with no
221 need to perform additional Transpose or register copy instructions.
222 The example above may be executed as a unit test and demo,
223 [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)
227 This section summarises the motivation for each REMAP Schedule
228 and briefly goes over their characteristics and limitations.
229 Further details on the Deterministic Precise-Interruptible algorithms
230 used in these Schedules is found in the [[sv/remap/appendix]].
232 ### Matrix (1D/2D/3D shaping)
234 Matrix Multiplication is a huge part of High-Performance Compute,
236 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
237 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
238 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
239 Aside from the cost of the load on the L1 I-Cache, the trick only
240 works if one of the dimensions X or Y are power-two. Prime Numbers
241 (5x7, 3x5) become deeply problematic to unroll.
243 Even traditional Scalable Vector ISAs have issues with Matrices, often
244 having to perform data Transpose by pushing out through Memory and back,
245 or computing Transposition Indices (costly) then copying to another
248 Matrix REMAP was thus designed to solve these issues by providing Hardware
250 "Schedules" that can view what would otherwise be limited to a strictly
251 linear Vector as instead being 2D (even 3D) *in-place* reordered.
252 With both Transposition and non-power-two being supported the issues
253 faced by other ISAs are mitigated.
255 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
256 restricted to 127: up to 127 FMAs (or other operation)
257 may be performed in total.
258 Also given that it is in-registers only at present some care has to be
259 taken on regfile resource utilisation. However it is perfectly possible
260 to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
261 the usual 6-level large Matrix Multiply, without the usual difficulties
262 associated with SIMD.
264 Also the `svshape` instruction only provides access to part of the
265 Matrix REMAP capability. Rotation and mirroring need to be done by
266 programming the SVSHAPE SPRs directly, which can take a lot more
267 instructions. Future versions of SVP64 will include EXT1xx prefixed
268 variants (`psvshape`) which provide more comprehensive capacity and
269 mitigate the need to write direct to the SVSHAPE SPRs.
271 ### FFT/DCT Triple Loop
273 DCT and FFT are some of the most astonishingly used algorithms in
274 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
275 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
278 An in-depth analysis showed that it is possible to do in-place in-register
279 DCT and FFT as long as twin-result "butterfly" instructions are provided.
280 These can be found in the [[openpower/isa/svfparith]] page if performing
281 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
282 integer operations would be required)*. These "butterfly" instructions
283 avoid the need for a temporary register because the two array positions
284 being overwritten will be "in-flight" in any In-Order or Out-of-Order
287 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
288 accept predicate masks. Given that it is common to perform recursive
289 convolutions combining smaller Power-2 DCT/FFT to create larger DCT/FFTs
290 in practice the RADIX2 limit is not a problem. A Bluestein convolution
291 to compute arbitrary length is demonstrated by
292 [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
296 The purpose of Indexing is to provide a generalised version of
297 Vector ISA "Permute" instructions, such as VSX `vperm`. The
298 Indexing is abstracted out and may be applied to much more
299 than an element move/copy, and is not limited for example
300 to the number of bytes that can fit into a VSX register.
301 Indexing may be applied to LD/ST (even on Indexed LD/ST
302 instructions such as `sv.lbzx`), arithmetic operations,
303 extsw: there is no artificial limit.
305 The only major caveat is that the registers to be used as
306 Indices must not be modified by any instruction after Indexed Mode
307 is established, and neither must MAXVL be altered. Additionally,
308 no register used as an Index may exceed MAXVL-1.
311 these conditions results in `UNDEFINED` behaviour.
312 These conditions allow a Read-After-Write (RAW) Hazard to be created on
313 the entire range of Indices to be subsequently used, but a corresponding
314 Write-After-Read Hazard by any instruction that modifies the Indices
315 **does not have to be created**. Given the large number of registers
316 involved in Indexing this is a huge resource saving and reduction
317 in micro-architectural complexity. MAXVL is likewise
318 included in the RAW Hazards because it is involved in calculating
319 how many registers are to be considered Indices.
321 With these Hazard Mitigations in place, high-performance implementations
322 may read-cache the Indices at the point where a given `svindex` instruction
323 is called (or SVSHAPE SPRs - and MAXVL - directly altered) by issuing
324 background GPR register file reads whilst other instructions are being
327 The original motivation for Indexed REMAP was to mitigate the need to add
328 an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
329 a stand-alone instruction. Usually a Vector ISA would add a non-conflicting
330 variant (as in VSX `vperm`) but it is common to need to permute by source,
331 with the risk of conflict, that has to be resolved, for example, in AVX-512
334 Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
335 destinations), which on a superficial analysis may be perceived to be a
336 problem, until it is recalled that, firstly, Simple-V is designed specifically
337 to require Program Order to be respected, and that Matrix, DCT and FFT
338 all *already* critically depend on overlapping Reads/Writes: Matrix
339 uses overlapping registers as accumulators. Thus the Register Hazard
340 Management needed by Indexed REMAP *has* to be in place anyway.
342 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
343 clearly that of the additional reading of the GPRs to be used as Indices,
344 plus the setup cost associated with creating those same Indices.
345 If any Deterministic REMAP can cover the required task, clearly it
346 is adviseable to use it instead.
348 *Programmer's note: some algorithms may require skipping of Indices exceeding
349 VL-1, not MAXVL-1. This may be achieved programmatically by performing
350 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
351 and RB contains the value of VL returned from `setvl`. The resultant
352 CR Fields may then be used as Predicate Masks to exclude those operations
353 with an Index exceeding VL-1.*
355 ### Parallel Reduction
357 Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
358 (Power ISA v3.0B) operation is leveraged, unmodified, to give the
359 *appearance* and *effect* of Reduction.
361 In Horizontal-First Mode, Vector-result reduction **requires**
362 the destination to be a Vector, which will be used to store
363 intermediary results.
365 Given that the tree-reduction schedule is deterministic,
366 Interrupts and exceptions
367 can therefore also be precise. The final result will be in the first
368 non-predicate-masked-out destination element, but due again to
369 the deterministic schedule programmers may find uses for the intermediate
372 When Rc=1 a corresponding Vector of co-resultant CRs is also
373 created. No special action is taken: the result *and its CR Field*
374 are stored "as usual" exactly as all other SVP64 Rc=1 operations.
376 Note that the Schedule only makes sense on top of certain instructions:
377 X-Form with a Register Profile of `RT,RA,RB` is fine because two sources
378 and the destination are all the same type. Like Scalar
379 Reduction, nothing is prohibited:
380 the results of execution on an unsuitable instruction may simply
381 not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
382 may be used, and whilst it is down to the Programmer to walk through the
383 process the Programmer can be confident that the Parallel-Reduction is
384 guaranteed 100% Deterministic.
386 Critical to note regarding use of Parallel-Reduction REMAP is that,
387 exactly as with all REMAP Modes, the `svshape` instruction *requests*
388 a certain Vector Length (number of elements to reduce) and then
389 sets VL and MAXVL at the number of **operations** needed to be
390 carried out. Thus, equally as importantly, like Matrix REMAP
391 the total number of operations
392 is restricted to 127. Any Parallel-Reduction requiring more operations
393 will need to be done manually in batches (hierarchical
394 recursive Reduction).
396 Also important to note is that the Deterministic Schedule is arranged
397 so that some implementations *may* parallelise it (as long as doing so
398 respects Program Order and Register Hazards). Performance (speed)
400 implementation is neither strictly defined or guaranteed. As with
401 the Vulkan(tm) Specification, strict compliance is paramount whilst
402 performance is at the discretion of Implementors.
404 **Parallel-Reduction with Predication**
406 To avoid breaking the strict RISC-paradigm, keeping the Issue-Schedule
407 completely separate from the actual element-level (scalar) operations,
408 Move operations are **not** included in the Schedule. This means that
409 the Schedule leaves the final (scalar) result in the first-non-masked
410 element of the Vector used. With the predicate mask being dynamic
411 (but deterministic) this result could be anywhere.
413 If that result is needed to be moved to a (single) scalar register
414 then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
415 needed to get it, where the predicate is the exact same predicate used
416 in the prior Parallel-Reduction instruction.
418 * If there was only a single
419 bit in the predicate then the result will not have moved or been altered
420 from the source vector prior to the Reduction
421 * If there was more than one bit the result will be in the
422 first element with a predicate bit set.
424 In either case the result is in the element with the first bit set in
427 Programmer's Note: For *some* hardware implementations
428 the vector-to-scalar copy may be a slow operation, as may the Predicated
429 Parallel Reduction itself.
430 It may be better to perform a pre-copy
431 of the values, compressing them (VREDUCE-style) into a contiguous block,
432 which will guarantee that the result goes into the very first element
433 of the destination vector, in which case clearly no follow-up
434 vector-to-scalar MV operation is needed.
438 The simplest usage is to perform an overwrite, specifying all three
439 register operands the same.
442 svshape parallelreduce, 6
446 The Reduction Schedule will issue the Parallel Tree Reduction spanning
447 registers 8 through 13, by adjusting the offsets to RT, RA and RB as
448 necessary (see "Parallel Reduction algorithm" in a later section).
450 A non-overwrite is possible as well but just as with the overwrite
451 version, only those destination elements necessary for storing
452 intermediary computations will be written to: the remaining elements
453 will **not** be overwritten and will **not** be zero'd.
456 svshape parallelreduce, 6
460 However it is critical to note that if the source and destination are
461 not the same then the trick of using a follow-up vector-scalar MV will
464 ### Sub-Vector Horizontal Reduction
466 To achieve Sub-Vector Horizontal Reduction, Pack/Unpack should be enabled,
467 which will turn the Schedule around such that issuing of the Scalar
468 Defined Words is done with SUBVL looping as the inner loop not the
469 outer loop. Rc=1 with Sub-Vectors (SUBVL=2,3,4) is `UNDEFINED` behaviour.
471 ## Determining Register Hazards
473 For high-performance (Multi-Issue, Out-of-Order) systems it is critical
474 to be able to statically determine the extent of Vectors in order to
475 allocate pre-emptive Hazard protection. The next task is to eliminate
476 masked-out elements using predicate bits, freeing up the associated
479 For non-REMAP situations `VL` is sufficient to ascertain early
480 Hazard coverage, and with SVSTATE being a high priority cached
481 quantity at the same level of MSR and PC this is not a problem.
483 The problems come when REMAP is enabled. Indexed REMAP must instead
484 use `MAXVL` as the earliest (simplest)
485 batch-level Hazard Reservation indicator (after taking element-width
486 overriding on the Index source into consideration),
487 but Matrix, FFT and Parallel Reduction must all use completely different
488 schemes. The reason is that VL is used to step through the total
489 number of *operations*, not the number of registers.
490 The "Saving Grace" is that all of the REMAP Schedules are 100% Deterministic.
492 Advance-notice Parallel computation and subsequent cacheing
493 of all of these complex Deterministic REMAP Schedules is
494 *strongly recommended*, thus allowing clear and precise multi-issue
495 batched Hazard coverage to be deployed, *even for Indexed Mode*.
496 This is only possible for Indexed due to the strict guidelines
497 given to Programmers.
499 In short, there exists solutions to the problem of Hazard Management,
500 with varying degrees of refinement possible at correspondingly
501 increasing levels of complexity in hardware.
503 A reminder: when Rc=1 each result register (element) has an associated
504 co-result CR Field (one per result element). Thus above when determining
505 the Write-Hazards for result registers the corresponding Write-Hazards for the
506 corresponding associated co-result CR Field must not be forgotten, *including* when
509 ## REMAP area of SVSTATE SPR
511 The following bits of the SVSTATE SPR are used for REMAP:
513 |32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
514 | -- | -- | -- | -- | -- | ----- | ------ |
515 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
517 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
518 mi0-2 apply to RA, RB, RC respectively, as input registers, and
519 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
520 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
521 SVSHAPE is actively applied or not.
523 * bit 0 of SVme indicates if mi0 is applied to RA / FRA / BA / BFA
524 * bit 1 of SVme indicates if mi1 is applied to RB / FRB / BB
525 * bit 2 of SVme indicates if mi2 is applied to RC / FRC / BC
526 * bit 3 of SVme indicates if mo0 is applied to RT / FRT / BT / BF
527 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
528 (LD/ST-with-update has an implicit 2nd write register, RA)
530 The "persistence" bit if set will result in all Active REMAPs being applied
537 # svremap instruction <a name="svremap"> </a>
541 svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
543 |0 |6 |11 |13 |15 |17 |19 |21 | 22.25 |26..31 |
544 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
545 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
549 * svremap SVme,mi0,mi1,mi2,mo0,mo1,pst
554 # registers RA RB RC RT EA/FRS SVSHAPE0-3 indices
555 SVSTATE[32:33] <- mi0
556 SVSTATE[34:35] <- mi1
557 SVSTATE[36:37] <- mi2
558 SVSTATE[38:39] <- mo0
559 SVSTATE[40:41] <- mo1
560 # enable bit for RA RB RC RT EA/FRS
561 SVSTATE[42:46] <- SVme
562 # persistence bit (applies to more than one instruction)
566 Special Registers Altered:
572 `svremap` determines the relationship between registers and SVSHAPE SPRs.
573 The bitmask `SVme` determines which registers have a REMAP applied, and mi0-mo1
574 determine which shape is applied to an activated register. the `pst` bit if
575 cleared indicated that the REMAP operation shall only apply to the immediately-following
576 instruction. If set then REMAP remains permanently enabled until such time as it is
577 explicitly disabled, either by `setvl` setting a new MAXVL, or with another
578 `svremap` instruction. `svindex` and `svshape2` are also capable of setting or
579 clearing persistence, as well as partially covering a subset of the capability of
580 `svremap` to set register-to-SVSHAPE relationships.
582 Programmer's Note: applying non-persistent `svremap` to an instruction that has
583 no REMAP enabled or is a Scalar operation will obviously have no effect but
584 the bits 32 to 46 will at least have been set in SVSTATE. This may prove useful
585 when using `svindex` or `svshape2`.
587 Hardware Architectural Note: when persistence is not set it is critically important
588 to treat the `svremap` and the following SVP64 instruction as an indivisible fused operation.
589 *No state* is stored in the SVSTATE SPR in order to allow continuation should an
590 Interrupt occur between the two instructions. Thus, Interrupts must be prohibited
591 from occurring or other workaround deployed. When persistence is set this issue
594 It is critical to note that if persistence is clear `svremap` is the **only** way
595 to activate REMAP on any given (following) instruction. If persistence is set however then
596 **all** SVP64 instructions go through REMAP as long as `SVme` is non-zero.
602 # SHAPE Remapping SPRs
604 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
605 which have the same format.
607 Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
608 disabled: the register's elements are a linear (1D) vector.
610 |31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
611 |---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
612 |0b00 |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
613 |0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
614 |0b01 |submode|offset| invxyz | submode2| zdimsz |mode |xdimsz|DCT/FFT|
615 |0b10 |submode|offset| invxyz | rsvd | rsvd |rsvd |xdimsz|Preduce|
616 |0b11 | | | | | | | |rsvd |
618 mode sets different behaviours (straight matrix multiply, FFT, DCT).
620 * **mode=0b00** sets straight Matrix Mode
621 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
622 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
623 * **mode=0b10** sets "Parallel Reduction" Schedules.
625 ## Parallel Reduction Mode
627 Creates the Schedules for Parallel Tree Reduction.
629 * **submode=0b00** selects the left operand index
630 * **submode=0b01** selects the right operand index
632 * When bit 0 of `invxyz` is set, the order of the indices
633 in the inner for-loop are reversed. This has the side-effect
634 of placing the final reduced result in the last-predicated element.
635 It also has the indirect side-effect of swapping the source
636 registers: Left-operand index numbers will always exceed
637 Right-operand indices.
638 When clear, the reduced result will be in the first-predicated
639 element, and Left-operand indices will always be *less* than
641 * When bit 1 of `invxyz` is set, the order of the outer loop
642 step is inverted: stepping begins at the nearest power-of two
643 to half of the vector length and reduces by half each time.
644 When clear the step will begin at 2 and double on each
649 submode2=0 is for FFT. For FFT submode the following schedules may be
652 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
654 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
656 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
658 When submode2 is 1 or 2, for DCT inner butterfly submode the following
659 schedules may be selected. When submode2 is 1, additional bit-reversing
662 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
664 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
665 in reverse-order, in-place
666 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
667 useful for calculating the cosine coefficient
668 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
669 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
671 When submode2 is 3 or 4, for DCT outer butterfly submode the following
672 schedules may be selected. When submode is 3, additional bit-reversing
675 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
676 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
678 `zdimsz` is used as an in-place "Stride", particularly useful for
679 column-based in-place DCT/FFT.
683 In Matrix Mode, skip allows dimensions to be skipped from being included
684 in the resultant output index. this allows sequences to be repeated:
685 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
686 modulo ```0 1 2 0 1 2 ...```
688 * **skip=0b00** indicates no dimensions to be skipped
689 * **skip=0b01** sets "skip 1st dimension"
690 * **skip=0b10** sets "skip 2nd dimension"
691 * **skip=0b11** sets "skip 3rd dimension"
693 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
694 zero then x-dimensional counting begins from 0 and increments, otherwise
695 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
697 offset will have the effect of offsetting the result by ```offset``` elements:
701 GPR(RT + remap(i) + SVSHAPE.offset) = ....
704 this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
705 bear in mind that unlike a static compiler SVSHAPE.offset may
706 be set dynamically at runtime.
708 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
709 that the array dimensionality for that dimension is 1. any dimension
710 not intended to be used must have its value set to 0 (dimensionality
711 of 1). A value of xdimsz=2 would indicate that in the first dimension
712 there are 3 elements in the array. For example, to create a 2D array
713 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
715 The format of the array is therefore as follows:
718 array[xdimsz+1][ydimsz+1][zdimsz+1]
721 However whilst illustrative of the dimensionality, that does not take the
722 "permute" setting into account. "permute" may be any one of six values
723 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
724 below shows how the permutation dimensionality order works:
726 | permute | order | array format |
727 | ------- | ----- | ------------------------ |
728 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
729 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
730 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
731 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
732 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
733 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
734 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
735 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
737 In other words, the "permute" option changes the order in which
738 nested for-loops over the array would be done. See executable
739 python reference code for further details.
741 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
744 With all these options it is possible to support in-place transpose,
745 in-place rotate, Matrix Multiply and Convolutions, without being
746 limited to Power-of-Two dimension sizes.
750 Indexed Mode activates reading of the element indices from the GPR
751 and includes optional limited 2D reordering.
752 In its simplest form (without elwidth overrides or other modes):
756 return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
759 element_result = ....
760 GPR(RT + indexed_remap(i)) = element_result
763 With element-width overrides included, and using the pseudocode
764 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
769 svreg = SVSHAPE.SVGPR << 1
770 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
771 offs = SVSHAPE.offset
772 return get_polymorphed_reg(svreg, srcwid, i) + offs
775 element_result = ....
776 rt_idx = indexed_remap(i)
777 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
780 Matrix-style reordering still applies to the indices, except limited
781 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
782 (Y,X) for in-place Transposition.
783 Only one dimension may optionally be skipped. Inversion of either
784 X or Y or both is possible (2D mirroring). Pseudocode for Indexed Mode (including elwidth
785 overrides) may be written in terms of Matrix Mode, specifically
786 purposed to ensure that the 3rd dimension (Z) has no effect:
789 def index_remap(ISHAPE, i):
790 MSHAPE.skip = 0b0 || ISHAPE.sk1
791 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
792 MSHAPE.xdimsz = ISHAPE.xdimsz
793 MSHAPE.ydimsz = ISHAPE.ydimsz
794 MSHAPE.zdimsz = 0 # disabled
795 if ISHAPE.permute = 0b110 # 0,1
796 MSHAPE.permute = 0b000 # 0,1,2
797 if ISHAPE.permute = 0b111 # 1,0
798 MSHAPE.permute = 0b010 # 1,0,2
799 el_idx = remap_matrix(MSHAPE, i)
800 svreg = ISHAPE.SVGPR << 1
801 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
803 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
806 The most important observation above is that the Matrix-style
807 remapping occurs first and the Index lookup second. Thus it
808 becomes possible to perform in-place Transpose of Indices which
809 may have been costly to set up or costly to duplicate
810 (waste register file space).
816 # svshape instruction <a name="svshape"> </a>
818 Form: SVM-Form SV "Matrix" Form (see [[isatables/fields.text]])
820 svshape SVxd,SVyd,SVzd,SVRM,vf
822 | 0.5|6.10 |11.15 |16..20 | 21..24 | 25 | 26..31| name |
823 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
824 |OPCD| SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
827 # for convenience, VL to be calculated and stored in SVSTATE
829 mscale[0:5] <- 0b000001 # for scaling MAXVL
830 itercount[0:6] <- [0] * 7
831 SVSTATE[0:31] <- [0] * 32
832 # only overwrite REMAP if "persistence" is zero
833 if (SVSTATE[62] = 0b0) then
834 SVSTATE[32:33] <- 0b00
835 SVSTATE[34:35] <- 0b00
836 SVSTATE[36:37] <- 0b00
837 SVSTATE[38:39] <- 0b00
838 SVSTATE[40:41] <- 0b00
839 SVSTATE[42:46] <- 0b00000
842 # clear out all SVSHAPEs
843 SVSHAPE0[0:31] <- [0] * 32
844 SVSHAPE1[0:31] <- [0] * 32
845 SVSHAPE2[0:31] <- [0] * 32
846 SVSHAPE3[0:31] <- [0] * 32
848 # set schedule up for multiply
849 if (SVrm = 0b0000) then
850 # VL in Matrix Multiply is xd*yd*zd
851 xd <- (0b00 || SVxd) + 1
852 yd <- (0b00 || SVyd) + 1
853 zd <- (0b00 || SVzd) + 1
855 vlen[0:6] <- n[14:20]
856 # set up template in SVSHAPE0, then copy to 1-3
857 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
858 SVSHAPE0[6:11] <- (0b0 || SVyd) # ydim
859 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim
860 SVSHAPE0[28:29] <- 0b11 # skip z
862 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
863 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
864 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
866 SVSHAPE1[18:20] <- 0b001 # permute x,z,y
867 SVSHAPE1[28:29] <- 0b01 # skip z
869 SVSHAPE2[18:20] <- 0b001 # permute x,z,y
870 SVSHAPE2[28:29] <- 0b11 # skip y
872 # set schedule up for FFT butterfly
873 if (SVrm = 0b0001) then
874 # calculate O(N log2 N)
877 if SVxd[4-n] = 0 then
880 n <- ((0b0 || SVxd) + 1) * n
882 # set up template in SVSHAPE0, then copy to 1-3
884 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
885 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D FFT)
886 mscale <- (0b0 || SVzd) + 1
887 SVSHAPE0[30:31] <- 0b01 # Butterfly mode
889 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
890 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
892 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
894 SVSHAPE2[28:29] <- 0b10 # k schedule
896 # set schedule up for (i)DCT Inner butterfly
897 # SVrm Mode 4 (Mode 12 for iDCT) is for on-the-fly (Vertical-First Mode)
898 if ((SVrm = 0b0100) |
899 (SVrm = 0b1100)) then
900 # calculate O(N log2 N)
903 if SVxd[4-n] = 0 then
906 n <- ((0b0 || SVxd) + 1) * n
908 # set up template in SVSHAPE0, then copy to 1-3
910 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
911 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
912 mscale <- (0b0 || SVzd) + 1
913 if (SVrm = 0b1100) then
914 SVSHAPE0[30:31] <- 0b11 # iDCT mode
915 SVSHAPE0[18:20] <- 0b011 # iDCT Inner Butterfly sub-mode
917 SVSHAPE0[30:31] <- 0b01 # DCT mode
918 SVSHAPE0[18:20] <- 0b001 # DCT Inner Butterfly sub-mode
919 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop
920 SVSHAPE0[6:11] <- 0b000011 # (i)DCT Inner Butterfly mode 4
922 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
923 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
924 if (SVrm != 0b0100) & (SVrm != 0b1100) then
925 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
927 SVSHAPE0[28:29] <- 0b01 # j+halfstep schedule
928 # for cos coefficient
929 SVSHAPE2[28:29] <- 0b10 # ci (k for mode 4) schedule
930 SVSHAPE2[12:17] <- 0b000000 # reset costable "striding" to 1
931 if (SVrm != 0b0100) & (SVrm != 0b1100) then
932 SVSHAPE3[28:29] <- 0b11 # size schedule
934 # set schedule up for (i)DCT Outer butterfly
935 if (SVrm = 0b0011) | (SVrm = 0b1011) then
936 # calculate O(N log2 N) number of outer butterfly overlapping adds
940 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
941 itercount[0:6] <- (0b0 || itercount[0:5])
943 if SVxd[4-n] = 0 then
946 count <- (itercount - 0b0000001) * size
947 vlen[0:6] <- vlen + count[7:13]
948 size[0:6] <- (size[1:6] || 0b0)
949 itercount[0:6] <- (0b0 || itercount[0:5])
950 # set up template in SVSHAPE0, then copy to 1-3
952 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
953 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
954 mscale <- (0b0 || SVzd) + 1
955 if (SVrm = 0b1011) then
956 SVSHAPE0[30:31] <- 0b11 # iDCT mode
957 SVSHAPE0[18:20] <- 0b011 # iDCT Outer Butterfly sub-mode
958 SVSHAPE0[21:23] <- 0b101 # "inverse" on outer and inner loop
960 SVSHAPE0[30:31] <- 0b01 # DCT mode
961 SVSHAPE0[18:20] <- 0b100 # DCT Outer Butterfly sub-mode
962 SVSHAPE0[6:11] <- 0b000010 # DCT Butterfly mode
964 SVSHAPE1[0:31] <- SVSHAPE0[0:31] # j+halfstep schedule
965 SVSHAPE2[0:31] <- SVSHAPE0[0:31] # costable coefficients
967 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
968 # reset costable "striding" to 1
969 SVSHAPE2[12:17] <- 0b000000
971 # set schedule up for DCT COS table generation
972 if (SVrm = 0b0101) | (SVrm = 0b1101) then
973 # calculate O(N log2 N)
975 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
976 itercount[0:6] <- (0b0 || itercount[0:5])
979 if SVxd[4-n] = 0 then
982 vlen[0:6] <- vlen + itercount
983 itercount[0:6] <- (0b0 || itercount[0:5])
984 # set up template in SVSHAPE0, then copy to 1-3
986 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
987 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
988 mscale <- (0b0 || SVzd) + 1
989 SVSHAPE0[30:31] <- 0b01 # DCT/FFT mode
990 SVSHAPE0[6:11] <- 0b000100 # DCT Inner Butterfly COS-gen mode
991 if (SVrm = 0b0101) then
992 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop for DCT
994 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
995 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
996 # for cos coefficient
997 SVSHAPE1[28:29] <- 0b10 # ci schedule
998 SVSHAPE2[28:29] <- 0b11 # size schedule
1000 # set schedule up for iDCT / DCT inverse of half-swapped ordering
1001 if (SVrm = 0b0110) | (SVrm = 0b1110) | (SVrm = 0b1111) then
1002 vlen[0:6] <- (0b00 || SVxd) + 0b0000001
1003 # set up template in SVSHAPE0
1004 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
1005 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
1006 mscale <- (0b0 || SVzd) + 1
1007 if (SVrm = 0b1110) then
1008 SVSHAPE0[18:20] <- 0b001 # DCT opposite half-swap
1009 if (SVrm = 0b1111) then
1010 SVSHAPE0[30:31] <- 0b01 # FFT mode
1012 SVSHAPE0[30:31] <- 0b11 # DCT mode
1013 SVSHAPE0[6:11] <- 0b000101 # DCT "half-swap" mode
1015 # set schedule up for parallel reduction
1016 if (SVrm = 0b0111) then
1017 # calculate the total number of operations (brute-force)
1018 vlen[0:6] <- [0] * 7
1019 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
1020 step[0:6] <- 0b0000001
1022 do while step <u itercount
1023 newstep <- step[1:6] || 0b0
1025 do while (j+step <u itercount)
1029 # VL in Parallel-Reduce is the number of operations
1031 # set up template in SVSHAPE0, then copy to 1. only 2 needed
1032 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
1033 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
1034 mscale <- (0b0 || SVzd) + 1
1035 SVSHAPE0[30:31] <- 0b10 # parallel reduce submode
1037 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
1038 # set up right operand (left operand 28:29 is zero)
1039 SVSHAPE1[28:29] <- 0b01 # right operand
1041 # set VL, MVL and Vertical-First
1042 m[0:12] <- vlen * mscale
1043 maxvl[0:6] <- m[6:12]
1044 SVSTATE[0:6] <- maxvl # MAVXL
1045 SVSTATE[7:13] <- vlen # VL
1049 Special Registers Altered:
1055 `svshape` is a convenience instruction that reduces instruction
1056 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
1057 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
1058 including VL and MAXVL. Using `svshape` therefore does not also
1063 * **SVxd** - SV REMAP "xdim"
1064 * **SVyd** - SV REMAP "ydim"
1065 * **SVzd** - SV REMAP "zdim"
1066 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
1067 * **vf** - sets "Vertical-First" mode
1069 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
1070 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
1072 There are 12 REMAP Modes (2 Modes are RESERVED for `svshape2`, 2 Modes
1075 | SVRM | Remap Mode description |
1077 | 0b0000 | Matrix 1/2/3D |
1078 | 0b0001 | FFT Butterfly |
1079 | 0b0010 | reserved |
1080 | 0b0011 | DCT Outer butterfly |
1081 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1082 | 0b0101 | DCT COS table index generation |
1083 | 0b0110 | DCT half-swap |
1084 | 0b0111 | Parallel Reduction |
1085 | 0b1000 | reserved for svshape2 |
1086 | 0b1001 | reserved for svshape2 |
1087 | 0b1010 | reserved |
1088 | 0b1011 | iDCT Outer butterfly |
1089 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1090 | 0b1101 | iDCT COS table index generation |
1091 | 0b1110 | iDCT half-swap |
1092 | 0b1111 | FFT half-swap |
1094 Examples showing how all of these Modes operate exists in the online
1095 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD). Explaining
1096 these Modes further in detail is beyond the scope of this document.
1098 In Indexed Mode, there are only 5 bits available to specify the GPR
1099 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
1100 5 bits are given in the `SVxd` field: the bottom two implicit bits
1101 will be zero (`SVxd || 0b00`).
1103 `svshape` has *limited applicability* due to being a 32-bit instruction.
1104 The full capability of SVSHAPE SPRs may be accessed by directly writing
1105 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
1106 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
1107 instruction, `psvshape`, may extend the capability here.
1109 *Architectural Resource Allocation note: the SVRM field is carefully
1110 crafted to allocate two Modes, corresponding to bits 21-23 within the
1111 instruction being set to the value `0b100`, to `svshape2` (not
1112 `svshape`). These two Modes are
1113 considered "RESERVED" within the context of `svshape` but it is
1114 absolutely critical to allocate the exact same pattern in XO for
1115 both instructions in bits 26-31.*
1122 # svindex instruction <a name="svindex"> </a>
1126 | 0-5|6-10 |11-15 |16-20 | 21-25 | 26-31 | Form |
1127 | -- | -- | --- | ---- | ----------- | ------| -------- |
1128 | PO | SVG | rmm | SVd | ew/yx/mm/sk | XO | SVI-Form |
1130 * svindex SVG,rmm,SVd,ew,SVyx,mm,sk
1135 # based on nearest MAXVL compute other dimension
1139 do while d*dim <u ([0]*4 || MVL)
1142 # set up template, then copy once location identified
1144 shape[30:31] <- 0b00 # mode
1146 shape[18:20] <- 0b110 # indexed xd/yd
1147 shape[0:5] <- (0b0 || SVd) # xdim
1148 if sk = 0 then shape[6:11] <- 0 # ydim
1149 else shape[6:11] <- 0b111111 # ydim max
1151 shape[18:20] <- 0b111 # indexed yd/xd
1152 if sk = 1 then shape[6:11] <- 0 # ydim
1153 else shape[6:11] <- d-1 # ydim max
1154 shape[0:5] <- (0b0 || SVd) # ydim
1155 shape[12:17] <- (0b0 || SVG) # SVGPR
1156 shape[28:29] <- ew # element-width override
1157 shape[21] <- sk # skip 1st dimension
1159 # select the mode for updating SVSHAPEs
1160 SVSTATE[62] <- mm # set or clear persistence
1162 # clear out all SVSHAPEs first
1163 SVSHAPE0[0:31] <- [0] * 32
1164 SVSHAPE1[0:31] <- [0] * 32
1165 SVSHAPE2[0:31] <- [0] * 32
1166 SVSHAPE3[0:31] <- [0] * 32
1167 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1168 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1172 # activate requested shape
1173 if idx = 0 then SVSHAPE0 <- shape
1174 if idx = 1 then SVSHAPE1 <- shape
1175 if idx = 2 then SVSHAPE2 <- shape
1176 if idx = 3 then SVSHAPE3 <- shape
1177 SVSTATE[bit*2+32:bit*2+33] <- idx
1178 # increment shape index, modulo 4
1179 if idx = 3 then idx <- 0
1182 # refined SVSHAPE/REMAP update mode
1185 if idx = 0 then SVSHAPE0 <- shape
1186 if idx = 1 then SVSHAPE1 <- shape
1187 if idx = 2 then SVSHAPE2 <- shape
1188 if idx = 3 then SVSHAPE3 <- shape
1189 SVSTATE[bit*2+32:bit*2+33] <- idx
1190 SVSTATE[46-bit] <- 1
1193 Special Registers Altered:
1199 `svindex` is a convenience instruction that reduces instruction count
1200 for Indexed REMAP Mode. It sets up (overwrites) all required SVSHAPE
1201 SPRs and **unlike** `svshape` can modify the REMAP area of the SVSTATE
1202 SPR as well, including setting persistence. The relevant SPRs *may*
1203 be directly programmed with `mtspr` however it is laborious to do so:
1204 svindex saves instructions covering much of Indexed REMAP capability.
1208 * **SVd** - SV REMAP x/y dim
1209 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
1211 * **ew** - sets element width override on the Indices
1212 * **SVG** - GPR SVG<<2 to be used for Indexing
1213 * **yx** - 2D reordering to be used if yx=1
1214 * **mm** - mask mode. determines how `rmm` is interpreted.
1215 * **sk** - Dimension skipping enabled
1217 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
1218 "off-by-one". In the assembler
1219 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
1221 *Note: when `yx=1,sk=0` the second dimension is calculated as
1226 * `rmm`, like REMAP.SVme, has bit 0
1227 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
1228 bit 3 to mo0 and bit 4 to mi1
1229 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
1230 * for each bit set in the 5-bit `rmm`, in order, the first
1231 as-yet-unset SVSHAPE will be updated
1232 with the other operands in the instruction, and the REMAP
1234 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
1235 * SVSTATE persistence bit is cleared
1236 * No other alterations to SVSTATE are carried out
1238 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
1239 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
1240 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
1241 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
1243 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
1244 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
1245 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
1247 Rough algorithmic form:
1250 marray = [mi0, mi1, mi2, mo0, mo1]
1253 if not rmm[bit]: continue
1255 SVSTATE{marray[bit]} = idx
1256 idx = (idx+1) modulo 4
1261 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
1262 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
1264 * only the selected SVSHAPE is overwritten
1265 * only the relevant bits in the REMAP area of SVSTATE are updated
1266 * REMAP persistence bit is set.
1268 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
1269 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
1270 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
1271 set to 2 (SVSHAPE2).
1273 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
1274 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
1275 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
1276 set to 3 (SVSHAPE3).
1278 Rough algorithmic form:
1281 marray = [mi0, mi1, mi2, mo0, mo1]
1285 SVSTATE{marray[bit]} = idx
1289 In essence, `mm=0` is intended for use to set as much of the
1290 REMAP State SPRs as practical with a single instruction,
1291 whilst `mm=1` is intended to be a little more refined.
1293 **Usage guidelines**
1295 * **Disable 2D mapping**: to only perform Indexing without
1296 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
1298 * **Modulo 1D mapping**: to perform Indexing cycling through the
1299 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
1300 no requirement to set VL equal to a multiple of N.
1301 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
1302 `xdim=M,ydim=CEIL(MAXVL/M)`.
1304 Beyond these mappings it becomes necessary to write directly to
1305 the SVSTATE SPRs manually.
1312 # svshape2 (offset-priority) <a name="svshape2"> </a>
1316 | 0-5|6-9 |10|11-15 |16-20 | 21-24 | 25 | 26-31 | Form |
1317 | -- |----|--| --- | ----- | ------ | -- | ------| -------- |
1318 | PO |offs|yx| rmm | SVd | 100/mm | sk | XO | SVM2-Form |
1320 * svshape2 offs,yx,rmm,SVd,sk,mm
1325 # based on nearest MAXVL compute other dimension
1329 do while d*dim <u ([0]*4 || MVL)
1331 # set up template, then copy once location identified
1333 shape[30:31] <- 0b00 # mode
1334 shape[0:5] <- (0b0 || SVd) # x/ydim
1336 shape[18:20] <- 0b000 # ordering xd/yd(/zd)
1337 if sk = 0 then shape[6:11] <- 0 # ydim
1338 else shape[6:11] <- 0b111111 # ydim max
1340 shape[18:20] <- 0b010 # ordering yd/xd(/zd)
1341 if sk = 1 then shape[6:11] <- 0 # ydim
1342 else shape[6:11] <- d-1 # ydim max
1343 # offset (the prime purpose of this instruction)
1344 shape[24:27] <- SVo # offset
1345 if sk = 1 then shape[28:29] <- 0b01 # skip 1st dimension
1346 else shape[28:29] <- 0b00 # no skipping
1347 # select the mode for updating SVSHAPEs
1348 SVSTATE[62] <- mm # set or clear persistence
1350 # clear out all SVSHAPEs first
1351 SVSHAPE0[0:31] <- [0] * 32
1352 SVSHAPE1[0:31] <- [0] * 32
1353 SVSHAPE2[0:31] <- [0] * 32
1354 SVSHAPE3[0:31] <- [0] * 32
1355 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1356 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1360 # activate requested shape
1361 if idx = 0 then SVSHAPE0 <- shape
1362 if idx = 1 then SVSHAPE1 <- shape
1363 if idx = 2 then SVSHAPE2 <- shape
1364 if idx = 3 then SVSHAPE3 <- shape
1365 SVSTATE[bit*2+32:bit*2+33] <- idx
1366 # increment shape index, modulo 4
1367 if idx = 3 then idx <- 0
1370 # refined SVSHAPE/REMAP update mode
1373 if idx = 0 then SVSHAPE0 <- shape
1374 if idx = 1 then SVSHAPE1 <- shape
1375 if idx = 2 then SVSHAPE2 <- shape
1376 if idx = 3 then SVSHAPE3 <- shape
1377 SVSTATE[bit*2+32:bit*2+33] <- idx
1378 SVSTATE[46-bit] <- 1
1381 Special Registers Altered:
1387 `svshape2` is an additional convenience instruction that prioritises
1388 setting `SVSHAPE.offset`. Its primary purpose is for use when
1389 element-width overrides are used. It has identical capabilities to `svindex` and
1390 in terms of both options (skip, etc.) and ability to activate REMAP
1391 (rmm, mask mode) but unlike `svindex` it does not set GPR REMAP,
1392 only a 1D or 2D `svshape`, and
1393 unlike `svshape` it can set an arbirrary `SVSHAPE.offset` immediate.
1395 One of the limitations of Simple-V is that Vector elements start on the boundary
1396 of the Scalar regfile, which is fine when element-width overrides are not
1397 needed. If the starting point of a Vector with smaller elwidths must begin
1398 in the middle of a register, normally there would be no way to do so except
1399 through LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`is
1404 * **offs** (4 bits) - unsigned offset
1405 * **yx** (1 bit) - swap XY to YX
1406 * **SVd** dimension size
1407 * **rmm** REMAP mask
1409 * **sk** (1 bit) skips 1st dimension if set
1411 Dimensions are calculated exactly as `svindex`. `rmm` and
1412 `mm` are as per `svindex`.
1414 *Programmer's Note: offsets for `svshape2` may be specified in the range
1415 0-15. Given that the principle of Simple-V is to fit on top of
1416 byte-addressable register files and that GPR and FPR are 64-bit (8 bytes)
1417 it should be clear that the offset may, when `elwidth=8`, begin an
1418 element-level operation starting element zero at any arbitrary byte.
1419 On cursory examination attempting to go beyond the range 0-7 seems
1420 unnecessary given that the **next GPR or FPR** is an
1421 alias for an offset in the range 8-15. Thus by simply increasing
1422 the starting Vector point of the operation to the next register it
1423 can be seen that the offset of 0-7 would be sufficient. Unfortunately
1424 however some operations are EXTRA2-encoded it is **not possible**
1425 to increase the GPR/FPR register number by one, because EXTRA2-encoding
1426 of GPR/FPR Vector numbers are restricted to even numbering.
1427 For CR Fields the EXTRA2 encoding is even more sparse.
1428 The additional offset range (8-15) helps overcome these limitations.*
1430 *Hardware Implementor's note: with the offsets only being immediates
1431 and with register numbering being entirely immediate as well it is
1432 possible to correctly compute Register Hazards without requiring
1433 reading the contents of any SPRs. If however there are
1434 instructions that have directly written to the SVSTATE or SVSHAPE
1435 SPRs and those instructions are still in-flight then this position
1436 is clearly **invalid**. This is why Programmers are strongly
1437 discouraged from directly writing to these SPRs.*
1439 *Architectural Resource Allocation note: this instruction shares
1440 the space of `svshape`. Therefore it is critical that the two
1441 instructions, `svshape` and `svshape2` have the exact same XO
1442 in bits 26 thru 31. It is also critical that for `svshape2`,
1443 bit 21 of XO is a 1, bit 22 of XO is a 0, and bit 23 of XO is a 0.*
1451 Add `SVI, SVM, SVRM` to `XO (26:31)` Field in Book I, 1.6.2
1453 Add the following to Book I, 1.6.1, SVI-Form
1456 |0 |6 |11 |16 |21 |23 |24|25|26 31|
1457 | PO | SVG|rmm | SVd |ew |SVyx|mm|sk| XO |
1460 Add the following to Book I, 1.6.1, SVM-Form
1463 |0 |6 |11 |16 |21 |25 |26 |31 |
1464 | PO | SVxd | SVyd | SVzd | SVrm |vf | XO |
1467 Add the following to Book I, 1.6.1, SVM2-Form
1470 |0 |6 |10 |11 |16 |21 |24|25 |26 |31 |
1471 | PO | SVo |SVyx| rmm | SVd |XO |mm|sk | XO |
1474 Add the following to Book I, 1.6.1, SVRM-Form
1477 |0 |6 |11 |13 |15 |17 |19 |21 |22 |26 |31 |
1478 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 |pst |/// | XO |
1481 Add the following to Book I, 1.6.2
1485 Field used in REMAP to select the SVSHAPE for 1st input register
1488 Field used in REMAP to select the SVSHAPE for 2nd input register
1491 Field used in REMAP to select the SVSHAPE for 3rd input register
1494 Field used to specify the meaning of the rmm field for SVI-Form
1498 Field used in REMAP to select the SVSHAPE for 1st output register
1501 Field used in REMAP to select the SVSHAPE for 2nd output register
1504 Field used in REMAP to indicate "persistence" mode (REMAP
1505 continues to apply to multiple instructions)
1508 REMAP Mode field for SVI-Form and SVM2-Form
1511 Field used to specify dimensional skipping in svindex
1514 Immediate field used to specify the size of the REMAP dimension
1515 in the svindex and svshape2 instructions
1518 Immediate field used to specify a 9-bit signed
1519 two's complement integer which is concatenated
1520 on the right with 0b00 and sign-extended to 64 bits.
1523 Field used to specify a GPR to be used as a
1524 source for indexing.
1527 Simple-V immediate field for setting VL or MVL
1530 Simple-V "REMAP" map-enable bits (0-4)
1533 Field used by the svshape2 instruction as an offset
1536 Simple-V "REMAP" Mode
1539 Simple-V "REMAP" x-dimension size
1542 Simple-V "REMAP" y-dimension size
1545 Simple-V "REMAP" z-dimension size
1548 Extended opcode field. Note that bit 21 must be 1, 22 and 23
1549 must be zero, and bits 26-31 must be exactly the same as
1556 Appendix E Power ISA sorted by opcode
1557 Appendix F Power ISA sorted by version
1558 Appendix G Power ISA sorted by Compliancy Subset
1559 Appendix H Power ISA sorted by mnemonic
1561 | Form | Book | Page | Version | mnemonic | Description |
1562 |------|------|------|---------|----------|-------------|
1563 | SVRM | I | # | 3.0B | svremap | REMAP enabling instruction |
1564 | SVM | I | # | 3.0B | svshape | REMAP shape instruction |
1565 | SVM2 | I | # | 3.0B | svshape2 | REMAP shape instruction (2) |
1566 | SVI | I | # | 3.0B | svindex | REMAP General-purpose Indexing |