1 # REMAP <a name="remap" />
4 * <https://bugs.libre-soc.org/show_bug.cgi?id=143> matrix multiply
5 * <https://bugs.libre-soc.org/show_bug.cgi?id=867> add svindex
6 * <https://bugs.libre-soc.org/show_bug.cgi?id=885> svindex in simulator
7 * <https://bugs.libre-soc.org/show_bug.cgi?id=911> offset svshape option
8 * <https://bugs.libre-soc.org/show_bug.cgi?id=864> parallel reduction
9 * <https://bugs.libre-soc.org/show_bug.cgi?id=930> DCT/FFT "strides"
10 * see [[sv/remap/appendix]] for examples and usage
11 * see [[sv/propagation]] for a future way to apply REMAP
12 * [[remap/discussion]]
15 REMAP is an advanced form of Vector "Structure Packing" that provides
16 hardware-level support for commonly-used *nested* loop patterns that would
17 otherwise require full inline loop unrolling. For more general reordering
18 an Indexed REMAP mode is available (a RISC-paradigm
19 abstracted analog to `xxperm`).
21 REMAP allows the usual sequential vector loop `0..VL-1` to be "reshaped"
22 (re-mapped) from a linear form to a 2D or 3D transposed form, or "offset"
23 to permit arbitrary access to elements (when elwidth overrides are
24 used), independently on each Vector src or dest register. Aside from
25 Indexed REMAP this is entirely Hardware-accelerated reordering and
26 consequently not costly in terms of register access. It will however
27 place a burden on Multi-Issue systems but no more than if the equivalent
28 Scalar instructions were explicitly loop-unrolled without SVP64, and
29 some advanced implementations may even find the Deterministic nature of
30 the Scheduling to be easier on resources.
32 The initial primary motivation of REMAP was for Matrix Multiplication,
33 reordering of sequential data in-place: in-place DCT and FFT were
34 easily justified given the exceptionally high usage in Computer Science.
35 Four SPRs are provided which may be applied to any GPR, FPR or CR Field so
36 that for example a single FMAC may be used in a single hardware-controlled
37 100% Deterministic loop to perform 5x3 times 3x4 Matrix multiplication,
38 generating 60 FMACs *without needing explicit assembler unrolling*.
39 Additional uses include regular "Structure Packing" such as RGB pixel
40 data extraction and reforming (although less costly vec2/3/4 reshaping
41 is achievable with `PACK/UNPACK`).
43 Even once designed as an independent RISC-paradigm abstraction system
44 it was realised that Matrix REMAP could be applied to min/max instructions to
45 achieve Floyd-Warshall Graph computations, or to AND/OR Ternary
46 bitmanipulation to compute Warshall Transitive Closure, or
47 to perform Cryptographic Matrix operations with Galois Field
48 variants of Multiply-Accumulate and many more uses expected to be
49 discovered. This *without
50 adding actual explicit Vector opcodes for any of the same*.
52 Thus it should be very clear:
53 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
54 Vector ISAs which would typically only have a limited set of instructions
55 that can be structure-packed (LD/ST and Move operations
56 being the most common), REMAP may be applied to
57 literally any instruction: CRs, Arithmetic, Logical, LD/ST, even
58 Vectorised Branch-Conditional.
60 When SUBVL is greater than 1 a given group of Subvector
61 elements are kept together: effectively the group becomes the
62 element, and with REMAP applying to elements
63 (not sub-elements) each group is REMAPed together.
64 Swizzle *can* however be applied to the same
65 instruction as REMAP, providing re-sequencing of
66 Subvector elements which REMAP cannot. Also as explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack Mode bits
67 can extend down into Sub-vector elements to influence vec2/vec3/vec4
68 sequential reordering, but even here, REMAP reordering is not *individually*
69 extended down to the actual sub-vector elements themselves.
70 This keeps the relevant Predicate Mask bit applicable to the Subvector
71 group, just as it does when REMAP is not active.
73 In its general form, REMAP is quite expensive to set up, and on some
74 implementations may introduce latency, so should realistically be used
75 only where it is worthwhile. Given that even with latency the fact
76 that up to 127 operations can be Deterministically issued (from a single
77 instruction) it should be clear that REMAP should not be dismissed
78 for *possible* latency alone. Commonly-used patterns such as Matrix
79 Multiply, DCT and FFT have helper instruction options which make REMAP
82 *Future specification note: future versions of the REMAP Management instructions
83 will extend to EXT1xx Prefixed variants. This will overcome some of the limitations
84 present in the 32-bit variants of the REMAP Management instructions that at
85 present require direct writing to SVSHAPE0-3 SPRs. Additional
86 REMAP Modes may also be introduced at that time.*
88 There are four types of REMAP:
90 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
91 Matrix transpose and rotate. The Shapes are set up for an "Outer Product"
93 * **FFT/DCT**, with full triple-loop in-place support: limited to
95 * **Indexing**, for any general-purpose reordering, also includes
96 limited 2D reshaping as well as Element "offsetting".
97 * **Parallel Reduction**, for scheduling a sequence of operations
98 in a Deterministic fashion, in a way that may be parallelised,
99 to reduce a Vector down to a single value.
101 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
102 REMAP Schedules are 100% Deterministic **including Indexing** and are
103 designed to be incorporated in between the Decode and Issue phases,
104 directly into Register Hazard Management.
106 As long as the SVSHAPE SPRs
107 are not written to directly, Hardware may treat REMAP as 100%
108 Deterministic: all REMAP Management instructions take static
109 operands (no dynamic register operands)
110 with the exception of Indexed Mode, and even then
111 Architectural State is permitted to assume that the Indices
112 are cacheable from the point at which the `svindex` instruction
115 Parallel Reduction is unusual in that it requires a full vector array
116 of results (not a scalar) and uses the rest of the result Vector for
117 the purposes of storing intermediary calculations. As these intermediary
118 results are Deterministically computed they may be useful.
119 Additionally, because the intermediate results are always written out
120 it is possible to service Precise Interrupts without affecting latency
121 (a common limitation of Vector ISAs implementing explicit
122 Parallel Reduction instructions, because their Architectural State cannot
123 hold the partial results).
127 The following illustrates why REMAP was added.
129 * normal vector element read/write of operands would be sequential
131 * this is not appropriate for (e.g.) Matrix multiply which requires
132 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
133 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
134 with this. both are expensive (copy large vectors, spill through memory)
135 and very few Packed SIMD ISAs cope with non-Power-2
136 (Duplicate-data inline-loop-unrolling is the costly solution)
137 * REMAP **redefines** the order of access according to set
138 (Deterministic) "Schedules".
139 * Matrix Schedules are not at all restricted to power-of-two boundaries
140 making it unnecessary to have for example specialised 3x4 transpose
141 instructions of other Vector ISAs.
142 * DCT and FFT REMAP are RADIX-2 limited but this is the case in existing Packed/Predicated
143 SIMD ISAs anyway (and Bluestein Convolution is typically deployed to
146 Only the most commonly-used algorithms in computer science have REMAP
147 support, due to the high cost in both the ISA and in hardware. For
148 arbitrary remapping the `Indexed` REMAP may be used.
152 * `svshape` to set the type of reordering to be applied to an
153 otherwise usual `0..VL-1` hardware for-loop
154 * `svremap` to set which registers a given reordering is to apply to
156 * `sv.{instruction}` where any Vectorised register marked by `svremap`
157 will have its ordering REMAPPED according to the schedule set
160 The following illustrative example multiplies a 3x4 and a 5x3
165 svshape 5,4,3,0,0 # Outer Product 5x4 by 4x3
166 svremap 15,1,2,3,0,0,0,0 # link Schedule to registers
167 sv.fmadds *0,*32,*64,*0 # 60 FMACs get executed here
170 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
171 * svremap activates four out of five registers RA RB RC RT RS (15)
177 - RS Remapping to not be activated
178 * sv.fmadds has vectors RT=0, RA=32, RB=64, RC=0
179 * With REMAP being active each register's element index is
180 *independently* transformed using the specified SHAPEs.
182 Thus the Vector Loop is arranged such that the use of
183 the multiply-and-accumulate instruction executes precisely the required
184 Schedule to perform an in-place in-registers Outer Product
185 Matrix Multiply with no
186 need to perform additional Transpose or register copy instructions.
187 The example above may be executed as a unit test and demo,
188 [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)
190 *Hardware Architectural note: with the Scheduling applying as a Phase between
191 Decode and Issue in a Deterministic fashion the Register Hazards may be
192 easily computed and a standard Out-of-Order Micro-Architecture exploited to good
193 effect. Even an In-Order system may observe that for large Outer Product
194 Schedules there will be no stalls, but if the Matrices are particularly
195 small size an In-Order system would have to stall, just as it would if
196 the operations were loop-unrolled without Simple-V. Thus: regardless
197 of the Micro-Architecture the Hardware Engineer should first consider
198 how best to process the exact same equivalent loop-unrolled instruction
203 This section summarises the motivation for each REMAP Schedule
204 and briefly goes over their characteristics and limitations.
205 Further details on the Deterministic Precise-Interruptible algorithms
206 used in these Schedules is found in the [[sv/remap/appendix]].
208 ### Matrix (1D/2D/3D shaping)
210 Matrix Multiplication is a huge part of High-Performance Compute,
212 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
213 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
214 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
215 Aside from the cost of the load on the L1 I-Cache, the trick only
216 works if one of the dimensions X or Y are power-two. Prime Numbers
217 (5x7, 3x5) become deeply problematic to unroll.
219 Even traditional Scalable Vector ISAs have issues with Matrices, often
220 having to perform data Transpose by pushing out through Memory and back,
221 or computing Transposition Indices (costly) then copying to another
224 Matrix REMAP was thus designed to solve these issues by providing Hardware
226 "Schedules" that can view what would otherwise be limited to a strictly
227 linear Vector as instead being 2D (even 3D) *in-place* reordered.
228 With both Transposition and non-power-two being supported the issues
229 faced by other ISAs are mitigated.
231 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
232 restricted to 127: up to 127 FMAs (or other operation)
233 may be performed in total.
234 Also given that it is in-registers only at present some care has to be
235 taken on regfile resource utilisation. However it is perfectly possible
236 to utilise Matrix REMAP to perform the three inner-most "kernel"
238 the usual 6-level large Matrix Multiply, without the usual difficulties
239 associated with SIMD.
241 Also the `svshape` instruction only provides access to part of the
242 Matrix REMAP capability. Rotation and mirroring need to be done by
243 programming the SVSHAPE SPRs directly, which can take a lot more
244 instructions. Future versions of SVP64 will include EXT1xx prefixed
245 variants (`psvshape`) which provide more comprehensive capacity and
246 mitigate the need to write direct to the SVSHAPE SPRs.
248 ### FFT/DCT Triple Loop
250 DCT and FFT are some of the most astonishingly used algorithms in
251 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
252 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
255 An in-depth analysis showed that it is possible to do in-place in-register
256 DCT and FFT as long as twin-result "butterfly" instructions are provided.
257 These can be found in the [[openpower/isa/svfparith]] page if performing
258 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
259 integer operations would be required)*. These "butterfly" instructions
260 avoid the need for a temporary register because the two array positions
261 being overwritten will be "in-flight" in any In-Order or Out-of-Order
264 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
265 accept predicate masks. Given that it is common to perform recursive
266 convolutions combining smaller Power-2 DCT/FFT to create larger DCT/FFTs
267 in practice the RADIX2 limit is not a problem. A Bluestein convolution
268 to compute arbitrary length is demonstrated by
269 [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
273 The purpose of Indexing is to provide a generalised version of
274 Vector ISA "Permute" instructions, such as VSX `vperm`. The
275 Indexing is abstracted out and may be applied to much more
276 than an element move/copy, and is not limited for example
277 to the number of bytes that can fit into a VSX register.
278 Indexing may be applied to LD/ST (even on Indexed LD/ST
279 instructions such as `sv.lbzx`), arithmetic operations,
280 extsw: there is no artificial limit.
282 The only major caveat is that the registers to be used as
283 Indices must not be modified by any instruction after Indexed Mode
284 is established, and neither must MAXVL be altered. Additionally,
285 no register used as an Index may exceed MAXVL-1.
288 these conditions results in `UNDEFINED` behaviour.
289 These conditions allow a Read-After-Write (RAW) Hazard to be created on
290 the entire range of Indices to be subsequently used, but a corresponding
291 Write-After-Read Hazard by any instruction that modifies the Indices
292 **does not have to be created**. Given the large number of registers
293 involved in Indexing this is a huge resource saving and reduction
294 in micro-architectural complexity. MAXVL is likewise
295 included in the RAW Hazards because it is involved in calculating
296 how many registers are to be considered Indices.
298 With these Hazard Mitigations in place, high-performance implementations
299 may read-cache the Indices at the point where a given `svindex` instruction
300 is called (or SVSHAPE SPRs - and MAXVL - directly altered) by issuing
301 background GPR register file reads whilst other instructions are being
304 The original motivation for Indexed REMAP was to mitigate the need to add
305 an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
306 a stand-alone instruction
307 (`GPR(RT) <- GPR(GPR(RA))`). Usually a Vector ISA would add a non-conflicting
308 variant (as in VSX `vperm`) but it is common to need to permute by source,
309 with the risk of conflict, that has to be resolved, for example, in AVX-512
312 Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
313 destinations), which on a superficial analysis may be perceived to be a
314 problem, until it is recalled that, firstly, Simple-V is designed specifically
315 to require Program Order to be respected, and that Matrix, DCT and FFT
316 all *already* critically depend on overlapping Reads/Writes: Matrix
317 uses overlapping registers as accumulators. Thus the Register Hazard
318 Management needed by Indexed REMAP *has* to be in place anyway.
320 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
321 clearly that of the additional reading of the GPRs to be used as Indices,
322 plus the setup cost associated with creating those same Indices.
323 If any Deterministic REMAP can cover the required task, clearly it
324 is adviseable to use it instead.
326 *Programmer's note: some algorithms may require skipping of Indices exceeding
327 VL-1, not MAXVL-1. This may be achieved programmatically by performing
328 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
329 and RB contains the value of VL returned from `setvl`. The resultant
330 CR Fields may then be used as Predicate Masks to exclude those operations
331 with an Index exceeding VL-1.*
333 ### Parallel Reduction
335 Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
336 (Power ISA v3.0B) operation is leveraged, unmodified, to give the
337 *appearance* and *effect* of Reduction.
339 In Horizontal-First Mode, Vector-result reduction **requires**
340 the destination to be a Vector, which will be used to store
341 intermediary results.
343 Given that the tree-reduction schedule is deterministic,
344 Interrupts and exceptions
345 can therefore also be precise. The final result will be in the first
346 non-predicate-masked-out destination element, but due again to
347 the deterministic schedule programmers may find uses for the intermediate
350 When Rc=1 a corresponding Vector of co-resultant CRs is also
351 created. No special action is taken: the result *and its CR Field*
352 are stored "as usual" exactly as all other SVP64 Rc=1 operations.
354 Note that the Schedule only makes sense on top of certain instructions:
355 X-Form with a Register Profile of `RT,RA,RB` is fine because two sources
356 and the destination are all the same type. Like Scalar
357 Reduction, nothing is prohibited:
358 the results of execution on an unsuitable instruction may simply
359 not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
360 may be used, and whilst it is down to the Programmer to walk through the
361 process the Programmer can be confident that the Parallel-Reduction is
362 guaranteed 100% Deterministic.
364 Critical to note regarding use of Parallel-Reduction REMAP is that,
365 exactly as with all REMAP Modes, the `svshape` instruction *requests*
366 a certain Vector Length (number of elements to reduce) and then
367 sets VL and MAXVL at the number of **operations** needed to be
368 carried out. Thus, equally as importantly, like Matrix REMAP
369 the total number of operations
370 is restricted to 127. Any Parallel-Reduction requiring more operations
371 will need to be done manually in batches (hierarchical
372 recursive Reduction).
374 Also important to note is that the Deterministic Schedule is arranged
375 so that some implementations *may* parallelise it (as long as doing so
376 respects Program Order and Register Hazards). Performance (speed)
378 implementation is neither strictly defined or guaranteed. As with
379 the Vulkan(tm) Specification, strict compliance is paramount whilst
380 performance is at the discretion of Implementors.
382 **Parallel-Reduction with Predication**
384 To avoid breaking the strict RISC-paradigm, keeping the Issue-Schedule
385 completely separate from the actual element-level (scalar) operations,
386 Move operations are **not** included in the Schedule. This means that
387 the Schedule leaves the final (scalar) result in the first-non-masked
388 element of the Vector used. With the predicate mask being dynamic
389 (but deterministic) this result could be anywhere.
391 If that result is needed to be moved to a (single) scalar register
392 then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
393 needed to get it, where the predicate is the exact same predicate used
394 in the prior Parallel-Reduction instruction.
396 * If there was only a single
397 bit in the predicate then the result will not have moved or been altered
398 from the source vector prior to the Reduction
399 * If there was more than one bit the result will be in the
400 first element with a predicate bit set.
402 In either case the result is in the element with the first bit set in
403 the predicate mask. Thus, no move/copy *within the Reduction itself* was needed.
405 Programmer's Note: For *some* hardware implementations
406 the vector-to-scalar copy may be a slow operation, as may the Predicated
407 Parallel Reduction itself.
408 It may be better to perform a pre-copy
409 of the values, compressing them (VREDUCE-style) into a contiguous block,
410 which will guarantee that the result goes into the very first element
411 of the destination vector, in which case clearly no follow-up
412 predicated vector-to-scalar MV operation is needed.
416 The simplest usage is to perform an overwrite, specifying all three
417 register operands the same.
420 svshape parallelreduce, 6
424 The Reduction Schedule will issue the Parallel Tree Reduction spanning
425 registers 8 through 13, by adjusting the offsets to RT, RA and RB as
426 necessary (see "Parallel Reduction algorithm" in a later section).
428 A non-overwrite is possible as well but just as with the overwrite
429 version, only those destination elements necessary for storing
430 intermediary computations will be written to: the remaining elements
431 will **not** be overwritten and will **not** be zero'd.
434 svshape parallelreduce, 6
438 However it is critical to note that if the source and destination are
439 not the same then the trick of using a follow-up vector-scalar MV will
442 ### Sub-Vector Horizontal Reduction
444 To achieve Sub-Vector Horizontal Reduction, Pack/Unpack should be enabled,
445 which will turn the Schedule around such that issuing of the Scalar
446 Defined Words is done with SUBVL looping as the inner loop not the
447 outer loop. Rc=1 with Sub-Vectors (SUBVL=2,3,4) is `UNDEFINED` behaviour.
449 ## Determining Register Hazards
451 For high-performance (Multi-Issue, Out-of-Order) systems it is critical
452 to be able to statically determine the extent of Vectors in order to
453 allocate pre-emptive Hazard protection. The next task is to eliminate
454 masked-out elements using predicate bits, freeing up the associated
457 For non-REMAP situations `VL` is sufficient to ascertain early
458 Hazard coverage, and with SVSTATE being a high priority cached
459 quantity at the same level of MSR and PC this is not a problem.
461 The problems come when REMAP is enabled. Indexed REMAP must instead
462 use `MAXVL` as the earliest (simplest)
463 batch-level Hazard Reservation indicator (after taking element-width
464 overriding on the Index source into consideration),
465 but Matrix, FFT and Parallel Reduction must all use completely different
466 schemes. The reason is that VL is used to step through the total
467 number of *operations*, not the number of registers.
468 The "Saving Grace" is that all of the REMAP Schedules are 100% Deterministic.
470 Advance-notice Parallel computation and subsequent cacheing
471 of all of these complex Deterministic REMAP Schedules is
472 *strongly recommended*, thus allowing clear and precise multi-issue
473 batched Hazard coverage to be deployed, *even for Indexed Mode*.
474 This is only possible for Indexed due to the strict guidelines
475 given to Programmers.
477 In short, there exists solutions to the problem of Hazard Management,
478 with varying degrees of refinement possible at correspondingly
479 increasing levels of complexity in hardware.
481 A reminder: when Rc=1 each result register (element) has an associated
482 co-result CR Field (one per result element). Thus above when determining
483 the Write-Hazards for result registers the corresponding Write-Hazards for the
484 corresponding associated co-result CR Field must not be forgotten, *including* when
487 ## REMAP area of SVSTATE SPR
489 The following bits of the SVSTATE SPR are used for REMAP:
492 |32:33|34:35|36:37|38:39|40:41| 42:46 | 62 |
493 | -- | -- | -- | -- | -- | ----- | ------ |
494 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
497 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
498 mi0-2 apply to RA, RB, RC respectively, as input registers, and
499 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
500 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
501 SVSHAPE is actively applied or not.
503 * bit 0 of SVme indicates if mi0 is applied to RA / FRA / BA / BFA
504 * bit 1 of SVme indicates if mi1 is applied to RB / FRB / BB
505 * bit 2 of SVme indicates if mi2 is applied to RC / FRC / BC
506 * bit 3 of SVme indicates if mo0 is applied to RT / FRT / BT / BF
507 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
508 (LD/ST-with-update has an implicit 2nd write register, RA)
510 The "persistence" bit if set will result in all Active REMAPs being applied
517 # svremap instruction <a name="svremap"> </a>
521 |0 |6 |11 |13 |15 |17 |19 |21 | 22:25 |26:31 |
522 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
523 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
525 * svremap SVme,mi0,mi1,mi2,mo0,mo1,pst
530 # registers RA RB RC RT EA/FRS SVSHAPE0-3 indices
531 SVSTATE[32:33] <- mi0
532 SVSTATE[34:35] <- mi1
533 SVSTATE[36:37] <- mi2
534 SVSTATE[38:39] <- mo0
535 SVSTATE[40:41] <- mo1
536 # enable bit for RA RB RC RT EA/FRS
537 SVSTATE[42:46] <- SVme
538 # persistence bit (applies to more than one instruction)
542 Special Registers Altered:
548 `svremap` determines the relationship between registers and SVSHAPE SPRs.
549 The bitmask `SVme` determines which registers have a REMAP applied, and mi0-mo1
550 determine which shape is applied to an activated register. the `pst` bit if
551 cleared indicated that the REMAP operation shall only apply to the immediately-following
552 instruction. If set then REMAP remains permanently enabled until such time as it is
553 explicitly disabled, either by `setvl` setting a new MAXVL, or with another
554 `svremap` instruction. `svindex` and `svshape2` are also capable of setting or
555 clearing persistence, as well as partially covering a subset of the capability of
556 `svremap` to set register-to-SVSHAPE relationships.
558 Programmer's Note: applying non-persistent `svremap` to an instruction that has
559 no REMAP enabled or is a Scalar operation will obviously have no effect but
560 the bits 32 to 46 will at least have been set in SVSTATE. This may prove useful
561 when using `svindex` or `svshape2`.
563 Hardware Architectural Note: when persistence is not set it is critically important
564 to treat the `svremap` and the following SVP64 instruction as an indivisible fused operation.
565 *No state* is stored in the SVSTATE SPR in order to allow continuation should an
566 Interrupt occur between the two instructions. Thus, Interrupts must be prohibited
567 from occurring or other workaround deployed. When persistence is set this issue
570 It is critical to note that if persistence is clear then `svremap` is the *only* way
571 to activate REMAP on any given (following) instruction. If persistence is set however then
572 **all** SVP64 instructions go through REMAP as long as `SVme` is non-zero.
578 # SHAPE Remapping SPRs
580 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
581 which have the same format.
583 Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
584 disabled: the register's elements are a linear (1D) vector.
586 |31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
587 |---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
588 |mode |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
589 |0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
590 |0b01 |submode|offset| invxyz | submode2| zdimsz |mode |xdimsz|DCT/FFT|
591 |0b10 |submode|offset| invxyz | rsvd | rsvd |rsvd |xdimsz|Preduce|
592 |0b11 | | | | | | | |rsvd |
594 mode sets different behaviours (straight matrix multiply, FFT, DCT).
596 * **mode=0b00** sets straight Matrix Mode
597 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
598 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
599 * **mode=0b10** sets "Parallel Reduction" Schedules.
601 ## Parallel Reduction Mode
603 Creates the Schedules for Parallel Tree Reduction.
605 * **submode=0b00** selects the left operand index
606 * **submode=0b01** selects the right operand index
608 * When bit 0 of `invxyz` is set, the order of the indices
609 in the inner for-loop are reversed. This has the side-effect
610 of placing the final reduced result in the last-predicated element.
611 It also has the indirect side-effect of swapping the source
612 registers: Left-operand index numbers will always exceed
613 Right-operand indices.
614 When clear, the reduced result will be in the first-predicated
615 element, and Left-operand indices will always be *less* than
617 * When bit 1 of `invxyz` is set, the order of the outer loop
618 step is inverted: stepping begins at the nearest power-of two
619 to half of the vector length and reduces by half each time.
620 When clear the step will begin at 2 and double on each
625 submode2=0 is for FFT. For FFT submode the following schedules may be
628 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
630 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
632 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
634 When submode2 is 1 or 2, for DCT inner butterfly submode the following
635 schedules may be selected. When submode2 is 1, additional bit-reversing
638 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
640 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
641 in reverse-order, in-place
642 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
643 useful for calculating the cosine coefficient
644 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
645 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
647 When submode2 is 3 or 4, for DCT outer butterfly submode the following
648 schedules may be selected. When submode is 3, additional bit-reversing
651 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
652 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
654 `zdimsz` is used as an in-place "Stride", particularly useful for
655 column-based in-place DCT/FFT.
659 In Matrix Mode, skip allows dimensions to be skipped from being included
660 in the resultant output index. this allows sequences to be repeated:
661 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
662 modulo ```0 1 2 0 1 2 ...```
664 * **skip=0b00** indicates no dimensions to be skipped
665 * **skip=0b01** sets "skip 1st dimension"
666 * **skip=0b10** sets "skip 2nd dimension"
667 * **skip=0b11** sets "skip 3rd dimension"
669 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
670 zero then x-dimensional counting begins from 0 and increments, otherwise
671 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
673 offset will have the effect of offsetting the result by ```offset``` elements:
677 GPR(RT + remap(i) + SVSHAPE.offset) = ....
680 this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
681 bear in mind that unlike a static compiler SVSHAPE.offset may
682 be set dynamically at runtime.
684 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
685 that the array dimensionality for that dimension is 1. any dimension
686 not intended to be used must have its value set to 0 (dimensionality
687 of 1). A value of xdimsz=2 would indicate that in the first dimension
688 there are 3 elements in the array. For example, to create a 2D array
689 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
691 The format of the array is therefore as follows:
694 array[xdimsz+1][ydimsz+1][zdimsz+1]
697 However whilst illustrative of the dimensionality, that does not take the
698 "permute" setting into account. "permute" may be any one of six values
699 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
700 below shows how the permutation dimensionality order works:
702 | permute | order | array format |
703 | ------- | ----- | ------------------------ |
704 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
705 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
706 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
707 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
708 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
709 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
710 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
711 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
713 In other words, the "permute" option changes the order in which
714 nested for-loops over the array would be done. See executable
715 python reference code for further details.
717 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
720 With all these options it is possible to support in-place transpose,
721 in-place rotate, Matrix Multiply and Convolutions, without being
722 limited to Power-of-Two dimension sizes.
726 Indexed Mode activates reading of the element indices from the GPR
727 and includes optional limited 2D reordering.
728 In its simplest form (without elwidth overrides or other modes):
732 return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
735 element_result = ....
736 GPR(RT + indexed_remap(i)) = element_result
739 With element-width overrides included, and using the pseudocode
740 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
745 svreg = SVSHAPE.SVGPR << 1
746 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
747 offs = SVSHAPE.offset
748 return get_polymorphed_reg(svreg, srcwid, i) + offs
751 element_result = ....
752 rt_idx = indexed_remap(i)
753 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
756 Matrix-style reordering still applies to the indices, except limited
757 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
758 (Y,X) for in-place Transposition.
759 Only one dimension may optionally be skipped. Inversion of either
760 X or Y or both is possible (2D mirroring). Pseudocode for Indexed Mode (including elwidth
761 overrides) may be written in terms of Matrix Mode, specifically
762 purposed to ensure that the 3rd dimension (Z) has no effect:
765 def index_remap(ISHAPE, i):
766 MSHAPE.skip = 0b0 || ISHAPE.sk1
767 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
768 MSHAPE.xdimsz = ISHAPE.xdimsz
769 MSHAPE.ydimsz = ISHAPE.ydimsz
770 MSHAPE.zdimsz = 0 # disabled
771 if ISHAPE.permute = 0b110 # 0,1
772 MSHAPE.permute = 0b000 # 0,1,2
773 if ISHAPE.permute = 0b111 # 1,0
774 MSHAPE.permute = 0b010 # 1,0,2
775 el_idx = remap_matrix(MSHAPE, i)
776 svreg = ISHAPE.SVGPR << 1
777 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
779 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
782 The most important observation above is that the Matrix-style
783 remapping occurs first and the Index lookup second. Thus it
784 becomes possible to perform in-place Transpose of Indices which
785 may have been costly to set up or costly to duplicate
786 (waste register file space).
792 # svshape instruction <a name="svshape"> </a>
796 svshape SVxd,SVyd,SVzd,SVRM,vf
798 | 0:5|6:10 |11:15 |16:20 | 21:24 | 25 | 26:31 | name |
799 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
800 |PO | SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
803 # for convenience, VL to be calculated and stored in SVSTATE
805 mscale[0:5] <- 0b000001 # for scaling MAXVL
806 itercount[0:6] <- [0] * 7
807 SVSTATE[0:31] <- [0] * 32
808 # only overwrite REMAP if "persistence" is zero
809 if (SVSTATE[62] = 0b0) then
810 SVSTATE[32:33] <- 0b00
811 SVSTATE[34:35] <- 0b00
812 SVSTATE[36:37] <- 0b00
813 SVSTATE[38:39] <- 0b00
814 SVSTATE[40:41] <- 0b00
815 SVSTATE[42:46] <- 0b00000
818 # clear out all SVSHAPEs
819 SVSHAPE0[0:31] <- [0] * 32
820 SVSHAPE1[0:31] <- [0] * 32
821 SVSHAPE2[0:31] <- [0] * 32
822 SVSHAPE3[0:31] <- [0] * 32
824 # set schedule up for multiply
825 if (SVrm = 0b0000) then
826 # VL in Matrix Multiply is xd*yd*zd
827 xd <- (0b00 || SVxd) + 1
828 yd <- (0b00 || SVyd) + 1
829 zd <- (0b00 || SVzd) + 1
831 vlen[0:6] <- n[14:20]
832 # set up template in SVSHAPE0, then copy to 1-3
833 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
834 SVSHAPE0[6:11] <- (0b0 || SVyd) # ydim
835 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim
836 SVSHAPE0[28:29] <- 0b11 # skip z
838 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
839 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
840 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
842 SVSHAPE1[18:20] <- 0b001 # permute x,z,y
843 SVSHAPE1[28:29] <- 0b01 # skip z
845 SVSHAPE2[18:20] <- 0b001 # permute x,z,y
846 SVSHAPE2[28:29] <- 0b11 # skip y
848 # set schedule up for FFT butterfly
849 if (SVrm = 0b0001) then
850 # calculate O(N log2 N)
853 if SVxd[4-n] = 0 then
856 n <- ((0b0 || SVxd) + 1) * n
858 # set up template in SVSHAPE0, then copy to 1-3
860 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
861 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D FFT)
862 mscale <- (0b0 || SVzd) + 1
863 SVSHAPE0[30:31] <- 0b01 # Butterfly mode
865 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
866 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
868 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
870 SVSHAPE2[28:29] <- 0b10 # k schedule
872 # set schedule up for (i)DCT Inner butterfly
873 # SVrm Mode 4 (Mode 12 for iDCT) is for on-the-fly (Vertical-First Mode)
874 if ((SVrm = 0b0100) |
875 (SVrm = 0b1100)) then
876 # calculate O(N log2 N)
879 if SVxd[4-n] = 0 then
882 n <- ((0b0 || SVxd) + 1) * n
884 # set up template in SVSHAPE0, then copy to 1-3
886 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
887 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
888 mscale <- (0b0 || SVzd) + 1
889 if (SVrm = 0b1100) then
890 SVSHAPE0[30:31] <- 0b11 # iDCT mode
891 SVSHAPE0[18:20] <- 0b011 # iDCT Inner Butterfly sub-mode
893 SVSHAPE0[30:31] <- 0b01 # DCT mode
894 SVSHAPE0[18:20] <- 0b001 # DCT Inner Butterfly sub-mode
895 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop
896 SVSHAPE0[6:11] <- 0b000011 # (i)DCT Inner Butterfly mode 4
898 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
899 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
900 if (SVrm != 0b0100) & (SVrm != 0b1100) then
901 SVSHAPE3[0:31] <- SVSHAPE0[0:31]
903 SVSHAPE0[28:29] <- 0b01 # j+halfstep schedule
904 # for cos coefficient
905 SVSHAPE2[28:29] <- 0b10 # ci (k for mode 4) schedule
906 SVSHAPE2[12:17] <- 0b000000 # reset costable "striding" to 1
907 if (SVrm != 0b0100) & (SVrm != 0b1100) then
908 SVSHAPE3[28:29] <- 0b11 # size schedule
910 # set schedule up for (i)DCT Outer butterfly
911 if (SVrm = 0b0011) | (SVrm = 0b1011) then
912 # calculate O(N log2 N) number of outer butterfly overlapping adds
916 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
917 itercount[0:6] <- (0b0 || itercount[0:5])
919 if SVxd[4-n] = 0 then
922 count <- (itercount - 0b0000001) * size
923 vlen[0:6] <- vlen + count[7:13]
924 size[0:6] <- (size[1:6] || 0b0)
925 itercount[0:6] <- (0b0 || itercount[0:5])
926 # set up template in SVSHAPE0, then copy to 1-3
928 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
929 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
930 mscale <- (0b0 || SVzd) + 1
931 if (SVrm = 0b1011) then
932 SVSHAPE0[30:31] <- 0b11 # iDCT mode
933 SVSHAPE0[18:20] <- 0b011 # iDCT Outer Butterfly sub-mode
934 SVSHAPE0[21:23] <- 0b101 # "inverse" on outer and inner loop
936 SVSHAPE0[30:31] <- 0b01 # DCT mode
937 SVSHAPE0[18:20] <- 0b100 # DCT Outer Butterfly sub-mode
938 SVSHAPE0[6:11] <- 0b000010 # DCT Butterfly mode
940 SVSHAPE1[0:31] <- SVSHAPE0[0:31] # j+halfstep schedule
941 SVSHAPE2[0:31] <- SVSHAPE0[0:31] # costable coefficients
943 SVSHAPE1[28:29] <- 0b01 # j+halfstep schedule
944 # reset costable "striding" to 1
945 SVSHAPE2[12:17] <- 0b000000
947 # set schedule up for DCT COS table generation
948 if (SVrm = 0b0101) | (SVrm = 0b1101) then
949 # calculate O(N log2 N)
951 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
952 itercount[0:6] <- (0b0 || itercount[0:5])
955 if SVxd[4-n] = 0 then
958 vlen[0:6] <- vlen + itercount
959 itercount[0:6] <- (0b0 || itercount[0:5])
960 # set up template in SVSHAPE0, then copy to 1-3
962 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
963 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
964 mscale <- (0b0 || SVzd) + 1
965 SVSHAPE0[30:31] <- 0b01 # DCT/FFT mode
966 SVSHAPE0[6:11] <- 0b000100 # DCT Inner Butterfly COS-gen mode
967 if (SVrm = 0b0101) then
968 SVSHAPE0[21:23] <- 0b001 # "inverse" on outer loop for DCT
970 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
971 SVSHAPE2[0:31] <- SVSHAPE0[0:31]
972 # for cos coefficient
973 SVSHAPE1[28:29] <- 0b10 # ci schedule
974 SVSHAPE2[28:29] <- 0b11 # size schedule
976 # set schedule up for iDCT / DCT inverse of half-swapped ordering
977 if (SVrm = 0b0110) | (SVrm = 0b1110) | (SVrm = 0b1111) then
978 vlen[0:6] <- (0b00 || SVxd) + 0b0000001
979 # set up template in SVSHAPE0
980 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
981 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
982 mscale <- (0b0 || SVzd) + 1
983 if (SVrm = 0b1110) then
984 SVSHAPE0[18:20] <- 0b001 # DCT opposite half-swap
985 if (SVrm = 0b1111) then
986 SVSHAPE0[30:31] <- 0b01 # FFT mode
988 SVSHAPE0[30:31] <- 0b11 # DCT mode
989 SVSHAPE0[6:11] <- 0b000101 # DCT "half-swap" mode
991 # set schedule up for parallel reduction
992 if (SVrm = 0b0111) then
993 # calculate the total number of operations (brute-force)
995 itercount[0:6] <- (0b00 || SVxd) + 0b0000001
996 step[0:6] <- 0b0000001
998 do while step <u itercount
999 newstep <- step[1:6] || 0b0
1001 do while (j+step <u itercount)
1005 # VL in Parallel-Reduce is the number of operations
1007 # set up template in SVSHAPE0, then copy to 1. only 2 needed
1008 SVSHAPE0[0:5] <- (0b0 || SVxd) # xdim
1009 SVSHAPE0[12:17] <- (0b0 || SVzd) # zdim - "striding" (2D DCT)
1010 mscale <- (0b0 || SVzd) + 1
1011 SVSHAPE0[30:31] <- 0b10 # parallel reduce submode
1013 SVSHAPE1[0:31] <- SVSHAPE0[0:31]
1014 # set up right operand (left operand 28:29 is zero)
1015 SVSHAPE1[28:29] <- 0b01 # right operand
1017 # set VL, MVL and Vertical-First
1018 m[0:12] <- vlen * mscale
1019 maxvl[0:6] <- m[6:12]
1020 SVSTATE[0:6] <- maxvl # MAVXL
1021 SVSTATE[7:13] <- vlen # VL
1025 Special Registers Altered:
1031 `svshape` is a convenience instruction that reduces instruction
1032 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
1033 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
1034 including VL and MAXVL. Using `svshape` therefore does not also
1039 * **SVxd** - SV REMAP "xdim"
1040 * **SVyd** - SV REMAP "ydim"
1041 * **SVzd** - SV REMAP "zdim"
1042 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
1043 * **vf** - sets "Vertical-First" mode
1044 * **XO** - standard 6-bit XO field
1046 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
1047 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
1049 There are 12 REMAP Modes (2 Modes are RESERVED for `svshape2`, 2 Modes
1052 | SVRM | Remap Mode description |
1054 | 0b0000 | Matrix 1/2/3D |
1055 | 0b0001 | FFT Butterfly |
1056 | 0b0010 | reserved |
1057 | 0b0011 | DCT Outer butterfly |
1058 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1059 | 0b0101 | DCT COS table index generation |
1060 | 0b0110 | DCT half-swap |
1061 | 0b0111 | Parallel Reduction |
1062 | 0b1000 | reserved for svshape2 |
1063 | 0b1001 | reserved for svshape2 |
1064 | 0b1010 | reserved |
1065 | 0b1011 | iDCT Outer butterfly |
1066 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
1067 | 0b1101 | iDCT COS table index generation |
1068 | 0b1110 | iDCT half-swap |
1069 | 0b1111 | FFT half-swap |
1071 Examples showing how all of these Modes operate exists in the online
1072 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD). Explaining
1073 these Modes further in detail is beyond the scope of this document.
1075 In Indexed Mode, there are only 5 bits available to specify the GPR
1076 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
1077 5 bits are given in the `SVxd` field: the bottom two implicit bits
1078 will be zero (`SVxd || 0b00`).
1080 `svshape` has *limited applicability* due to being a 32-bit instruction.
1081 The full capability of SVSHAPE SPRs may be accessed by directly writing
1082 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
1083 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
1084 instruction, `psvshape`, may extend the capability here.
1086 *Architectural Resource Allocation note: the SVRM field is carefully
1087 crafted to allocate two Modes, corresponding to bits 21-23 within the
1088 instruction being set to the value `0b100`, to `svshape2` (not
1089 `svshape`). These two Modes are
1090 considered "RESERVED" within the context of `svshape` but it is
1091 absolutely critical to allocate the exact same pattern in XO for
1092 both instructions in bits 26-31.*
1099 # svindex instruction <a name="svindex"> </a>
1103 | 0:5|6:10 |11:15 |16:20 | 21:25 | 26:31 | Form |
1104 | -- | -- | --- | ---- | ----------- | ------| -------- |
1105 | PO | SVG | rmm | SVd | ew/yx/mm/sk | XO | SVI-Form |
1107 * svindex SVG,rmm,SVd,ew,SVyx,mm,sk
1112 # based on nearest MAXVL compute other dimension
1116 do while d*dim <u ([0]*4 || MVL)
1119 # set up template, then copy once location identified
1121 shape[30:31] <- 0b00 # mode
1123 shape[18:20] <- 0b110 # indexed xd/yd
1124 shape[0:5] <- (0b0 || SVd) # xdim
1125 if sk = 0 then shape[6:11] <- 0 # ydim
1126 else shape[6:11] <- 0b111111 # ydim max
1128 shape[18:20] <- 0b111 # indexed yd/xd
1129 if sk = 1 then shape[6:11] <- 0 # ydim
1130 else shape[6:11] <- d-1 # ydim max
1131 shape[0:5] <- (0b0 || SVd) # ydim
1132 shape[12:17] <- (0b0 || SVG) # SVGPR
1133 shape[28:29] <- ew # element-width override
1134 shape[21] <- sk # skip 1st dimension
1136 # select the mode for updating SVSHAPEs
1137 SVSTATE[62] <- mm # set or clear persistence
1139 # clear out all SVSHAPEs first
1140 SVSHAPE0[0:31] <- [0] * 32
1141 SVSHAPE1[0:31] <- [0] * 32
1142 SVSHAPE2[0:31] <- [0] * 32
1143 SVSHAPE3[0:31] <- [0] * 32
1144 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1145 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1149 # activate requested shape
1150 if idx = 0 then SVSHAPE0 <- shape
1151 if idx = 1 then SVSHAPE1 <- shape
1152 if idx = 2 then SVSHAPE2 <- shape
1153 if idx = 3 then SVSHAPE3 <- shape
1154 SVSTATE[bit*2+32:bit*2+33] <- idx
1155 # increment shape index, modulo 4
1156 if idx = 3 then idx <- 0
1159 # refined SVSHAPE/REMAP update mode
1162 if idx = 0 then SVSHAPE0 <- shape
1163 if idx = 1 then SVSHAPE1 <- shape
1164 if idx = 2 then SVSHAPE2 <- shape
1165 if idx = 3 then SVSHAPE3 <- shape
1166 SVSTATE[bit*2+32:bit*2+33] <- idx
1167 SVSTATE[46-bit] <- 1
1170 Special Registers Altered:
1176 `svindex` is a convenience instruction that reduces instruction count
1177 for Indexed REMAP Mode. It sets up (overwrites) all required SVSHAPE
1178 SPRs and **unlike** `svshape` can modify the REMAP area of the SVSTATE
1179 SPR as well, including setting persistence. The relevant SPRs *may*
1180 be directly programmed with `mtspr` however it is laborious to do so:
1181 svindex saves instructions covering much of Indexed REMAP capability.
1185 * **SVd** - SV REMAP x/y dim
1186 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
1188 * **ew** - sets element width override on the Indices
1189 * **SVG** - GPR SVG<<2 to be used for Indexing
1190 * **yx** - 2D reordering to be used if yx=1
1191 * **mm** - mask mode. determines how `rmm` is interpreted.
1192 * **sk** - Dimension skipping enabled
1194 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
1195 "off-by-one". In the assembler
1196 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
1198 *Note: when `yx=1,sk=0` the second dimension is calculated as
1203 * `rmm`, like REMAP.SVme, has bit 0
1204 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
1205 bit 3 to mo0 and bit 4 to mi1
1206 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
1207 * for each bit set in the 5-bit `rmm`, in order, the first
1208 as-yet-unset SVSHAPE will be updated
1209 with the other operands in the instruction, and the REMAP
1211 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
1212 * SVSTATE persistence bit is cleared
1213 * No other alterations to SVSTATE are carried out
1215 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
1216 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
1217 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
1218 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
1220 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
1221 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
1222 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
1224 Rough algorithmic form:
1227 marray = [mi0, mi1, mi2, mo0, mo1]
1230 if not rmm[bit]: continue
1232 SVSTATE{marray[bit]} = idx
1233 idx = (idx+1) modulo 4
1238 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
1239 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
1241 * only the selected SVSHAPE is overwritten
1242 * only the relevant bits in the REMAP area of SVSTATE are updated
1243 * REMAP persistence bit is set.
1245 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
1246 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
1247 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
1248 set to 2 (SVSHAPE2).
1250 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
1251 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
1252 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
1253 set to 3 (SVSHAPE3).
1255 Rough algorithmic form:
1258 marray = [mi0, mi1, mi2, mo0, mo1]
1262 SVSTATE{marray[bit]} = idx
1266 In essence, `mm=0` is intended for use to set as much of the
1267 REMAP State SPRs as practical with a single instruction,
1268 whilst `mm=1` is intended to be a little more refined.
1270 **Usage guidelines**
1272 * **Disable 2D mapping**: to only perform Indexing without
1273 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
1275 * **Modulo 1D mapping**: to perform Indexing cycling through the
1276 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
1277 no requirement to set VL equal to a multiple of N.
1278 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
1279 `xdim=M,ydim=CEIL(MAXVL/M)`.
1281 Beyond these mappings it becomes necessary to write directly to
1282 the SVSTATE SPRs manually.
1289 # svshape2 (offset-priority) <a name="svshape2"> </a>
1293 | 0:5|6:9 |10|11:15 |16:20 | 21:24 | 25 | 26:31 | Form |
1294 | -- |----|--| --- | ----- | ------ | -- | ------| -------- |
1295 | PO |offs|yx| rmm | SVd | 100/mm | sk | XO | SVM2-Form |
1297 * svshape2 offs,yx,rmm,SVd,sk,mm
1302 # based on nearest MAXVL compute other dimension
1306 do while d*dim <u ([0]*4 || MVL)
1308 # set up template, then copy once location identified
1310 shape[30:31] <- 0b00 # mode
1311 shape[0:5] <- (0b0 || SVd) # x/ydim
1313 shape[18:20] <- 0b000 # ordering xd/yd(/zd)
1314 if sk = 0 then shape[6:11] <- 0 # ydim
1315 else shape[6:11] <- 0b111111 # ydim max
1317 shape[18:20] <- 0b010 # ordering yd/xd(/zd)
1318 if sk = 1 then shape[6:11] <- 0 # ydim
1319 else shape[6:11] <- d-1 # ydim max
1320 # offset (the prime purpose of this instruction)
1321 shape[24:27] <- SVo # offset
1322 if sk = 1 then shape[28:29] <- 0b01 # skip 1st dimension
1323 else shape[28:29] <- 0b00 # no skipping
1324 # select the mode for updating SVSHAPEs
1325 SVSTATE[62] <- mm # set or clear persistence
1327 # clear out all SVSHAPEs first
1328 SVSHAPE0[0:31] <- [0] * 32
1329 SVSHAPE1[0:31] <- [0] * 32
1330 SVSHAPE2[0:31] <- [0] * 32
1331 SVSHAPE3[0:31] <- [0] * 32
1332 SVSTATE[32:41] <- [0] * 10 # clear REMAP.mi/o
1333 SVSTATE[42:46] <- rmm # rmm exactly REMAP.SVme
1337 # activate requested shape
1338 if idx = 0 then SVSHAPE0 <- shape
1339 if idx = 1 then SVSHAPE1 <- shape
1340 if idx = 2 then SVSHAPE2 <- shape
1341 if idx = 3 then SVSHAPE3 <- shape
1342 SVSTATE[bit*2+32:bit*2+33] <- idx
1343 # increment shape index, modulo 4
1344 if idx = 3 then idx <- 0
1347 # refined SVSHAPE/REMAP update mode
1350 if idx = 0 then SVSHAPE0 <- shape
1351 if idx = 1 then SVSHAPE1 <- shape
1352 if idx = 2 then SVSHAPE2 <- shape
1353 if idx = 3 then SVSHAPE3 <- shape
1354 SVSTATE[bit*2+32:bit*2+33] <- idx
1355 SVSTATE[46-bit] <- 1
1358 Special Registers Altered:
1364 `svshape2` is an additional convenience instruction that prioritises
1365 setting `SVSHAPE.offset`. Its primary purpose is for use when
1366 element-width overrides are used. It has identical capabilities to `svindex`
1367 in terms of both options (skip, etc.) and ability to activate REMAP
1368 (rmm, mask mode) but unlike `svindex` it does not set GPR REMAP:
1369 only a 1D or 2D `svshape`, and
1370 unlike `svshape` it can set an arbitrary `SVSHAPE.offset` immediate.
1372 One of the limitations of Simple-V is that Vector elements start on the boundary
1373 of the Scalar regfile, which is fine when element-width overrides are not
1374 needed. If the starting point of a Vector with smaller elwidths must begin
1375 in the middle of a register, normally there would be no way to do so except
1376 through costly LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`
1377 makes it easier to access.
1381 * **offs** (4 bits) - unsigned offset
1382 * **yx** (1 bit) - swap XY to YX
1383 * **SVd** dimension size
1384 * **rmm** REMAP mask
1386 * **sk** (1 bit) skips 1st dimension if set
1388 Dimensions are calculated exactly as `svindex`. `rmm` and
1389 `mm` are as per `svindex`.
1391 *Programmer's Note: offsets for `svshape2` may be specified in the range
1392 0-15. Given that the principle of Simple-V is to fit on top of
1393 byte-addressable register files and that GPR and FPR are 64-bit (8 bytes)
1394 it should be clear that the offset may, when `elwidth=8`, begin an
1395 element-level operation starting element zero at any arbitrary byte.
1396 On cursory examination attempting to go beyond the range 0-7 seems
1397 unnecessary given that the **next GPR or FPR** is an
1398 alias for an offset in the range 8-15. Thus by simply increasing
1399 the starting Vector point of the operation to the next register it
1400 can be seen that the offset of 0-7 would be sufficient. Unfortunately
1401 however some operations are EXTRA2-encoded it is **not possible**
1402 to increase the GPR/FPR register number by one, because EXTRA2-encoding
1403 of GPR/FPR Vector numbers are restricted to even numbering.
1404 For CR Fields the EXTRA2 encoding is even more sparse.
1405 The additional offset range (8-15) helps overcome these limitations.*
1407 *Hardware Implementor's note: with the offsets only being immediates
1408 and with register numbering being entirely immediate as well it is
1409 possible to correctly compute Register Hazards without requiring
1410 reading the contents of any SPRs. If however there are
1411 instructions that have directly written to the SVSTATE or SVSHAPE
1412 SPRs and those instructions are still in-flight then this position
1413 is clearly **invalid**. This is why Programmers are strongly
1414 discouraged from directly writing to these SPRs.*
1416 *Architectural Resource Allocation note: this instruction shares
1417 the space of `svshape`. Therefore it is critical that the two
1418 instructions, `svshape` and `svshape2` have the exact same XO
1419 in bits 26 thru 31. It is also critical that for `svshape2`,
1420 bit 21 of XO is a 1, bit 22 of XO is a 0, and bit 23 of XO is a 0.*