3 # REMAP <a name="remap" />
5 * <https://bugs.libre-soc.org/show_bug.cgi?id=143> matrix multiply
6 * <https://bugs.libre-soc.org/show_bug.cgi?id=867> add svindex
7 * <https://bugs.libre-soc.org/show_bug.cgi?id=885> svindex in simulator
8 * <https://bugs.libre-soc.org/show_bug.cgi?id=911> offset svshape option
9 * see [[sv/remap/appendix]] for examples and usage
10 * see [[sv/propagation]] for a future way to apply REMAP
11 * [[remap/discussion]]
13 REMAP is an advanced form of Vector "Structure Packing" that
14 provides hardware-level support for commonly-used *nested* loop patterns.
15 For more general reordering an Indexed REMAP mode is available.
17 REMAP allows the usual vector loop `0..VL-1` to be "reshaped" (re-mapped)
18 from a linear form to a 2D or 3D transposed form, or "offset" to permit
19 arbitrary access to elements (when elwidth overrides are used),
20 independently on each Vector src or dest
23 The initial primary motivation of REMAP was for Matrix Multiplication, reordering of sequential
24 data in-place: in-place DCT and FFT were easily justified given the
25 high usage in Computer Science.
26 Four SPRs are provided which may be applied to any GPR, FPR or CR Field
27 so that for example a single FMAC may be
28 used in a single loop to perform 5x3 times 3x4 Matrix multiplication,
29 generating 60 FMACs *without needing explicit assembler unrolling*.
30 Additional uses include regular "Structure Packing"
31 such as RGB pixel data extraction and reforming.
33 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
34 Vector ISAs which would typically only have a limited set of instructions
35 that can be structure-packed (LD/ST typically), REMAP may be applied to
36 literally any instruction: CRs, Arithmetic, Logical, LD/ST, anything.
38 Note that REMAP does not *directly* apply to sub-vector elements: that
39 is what swizzle is for. Swizzle *can* however be applied to the same
40 instruction as REMAP. As explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack EXTRA Mode bits
41 can extend down into Sub-vector elements to perform vec2/vec3/vec4
42 sequential reordering, but even here, REMAP is not extended down to
43 the actual sub-vector elements themselves.
45 In its general form, REMAP is quite expensive to set up, and on some
46 implementations may introduce
47 latency, so should realistically be used only where it is worthwhile.
48 Commonly-used patterns such as Matrix Multiply, DCT and FFT have
49 helper instruction options which make REMAP easier to use.
51 There are three types of REMAP:
53 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
54 Matrix transpose and rotate.
55 * **FFT/DCT**, with full triple-loop in-place support: limited to
57 * **Indexing**, for any general-purpose reordering, also includes
60 Best implemented on top of a Multi-Issue Out-of-Order Micro-architecture,
61 REMAP Schedules are 100% Deterministic **including Indexing** and are
62 designed to be incorporated in between the Decode and Issue phases,
63 directly into Register Hazard Management.
67 * normal vector element read/write of operands would be sequential
69 * this is not appropriate for (e.g.) Matrix multiply which requires
70 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
71 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
72 with this. both are expensive (copy large vectors, spill through memory)
73 and very few Packed SIMD ISAs cope with non-Power-2.
74 * REMAP **redefines** the order of access according to set "Schedules".
75 * The Schedules are not necessarily restricted to power-of-two boundaries
76 making it unnecessary to have for example specialised 3x4 transpose
79 Only the most commonly-used algorithms in computer science have REMAP
80 support, due to the high cost in both the ISA and in hardware. For
81 arbitrary remapping the `Indexed` REMAP may be used.
83 # Executive Summary Usage
85 * `svshape` to set the type of reordering to be applied to an
86 otherwise usual `0..VL-1` hardware for-loop
87 * `svremap` to set which registers a given reordering is to apply to
89 * `sv.{instruction}` where any Vectorised register marked by `svremap`
90 will have its ordering REMAPPED according to the schedule set
93 The following illustrative example multiplies a 3x4 and a 5x3
98 svremap 15, 1, 2, 3, 0, 0, 0, 0
99 sv.fmadds 0.v, 8.v, 16.v, 0.v
101 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
102 * svremap activates four out of five registers RA RB RC RT RS (15)
108 - RS Remapping to not be activated
109 * sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
110 * With REMAP being active each register's element index is
111 *independently* transformed using the specified SHAPEs.
113 Thus the Vector Loop is arranged such that the use of
114 the multiply-and-accumulate instruction executes precisely the required
115 Schedule to perform an in-place in-registers Matrix Multiply with no
116 need to perform additional Transpose or register copy instructions.
117 The example above may be executed as a unit test and demo,
118 [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)
122 This section summarises the motivation for each REMAP Schedule
123 and briefly goes over their characteristics and limitations.
124 Further details on the Deterministic Precise-Interruptible algorithms
125 used in these Schedules is found in the [[sv/remap/appendix]].
127 ## Matrix (1D/2D/3D shaping)
129 Matrix Multiplication is a huge part of High-Performance Compute,
131 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
132 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
133 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
134 Aside from the cost of the load on the L1 I-Cache, the trick only
135 works if one of the dimensions X or Y are power-two. Prime Numbers
136 (5x7, 3x5) become deeply problematic to unroll.
138 Even traditional Scalable Vector ISAs have issues with Matrices, often
139 having to perform data Transpose by pushing out through Memory and back,
140 or computing Transposition Indices (costly) then copying to another
143 Matrix REMAP was thus designed to solve these issues by providing Hardware
145 "Schedules" that can view what would otherwise be limited to a strictly
146 linear Vector as instead being 2D (even 3D) *in-place* reordered.
147 With both Transposition and non-power-two being supported the issues
148 faced by other ISAs are mitigated.
150 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
151 restricted to 127: up to 127 FMAs (or other operation)
152 may be performed in total.
153 Also given that it is in-registers only at present some care has to be
154 taken on regfile resource utilisation. However it is perfectly possible
155 to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
156 the usual 6-level large Matrix Multiply, without the usual difficulties
157 associated with SIMD.
159 Also the `svshape` instruction only provides access to part of the
160 Matrix REMAP capability. Rotation and mirroring need to be done by
161 programming the SVSHAPE SPRs directly, which can take a lot more
164 ## FFT/DCT Triple Loop
166 DCT and FFT are some of the most astonishingly used algorithms in
167 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
168 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
171 An in-depth analysis showed that it is possible to do in-place in-register
172 DCT and FFT as long as twin-result "butterfly" instructions are provided.
173 These can be found in the [[openpower/isa/svfparith]] page if performing
174 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
175 integer operations would be required)*. These "butterfly" instructions
176 avoid the need for a temporary register because the two array positions
177 being overwritten will be "in-flight" in any In-Order or Out-of-Order
180 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
181 accept predicate masks. Given that it is common to perform recursive
183 combining smaller Power-2 DCT/FFT to create larger DCT/FFTs in practice the RADIX2
184 limit is not a problem. A Bluestein convolution to compute arbitrary
185 length is demonstrated
186 by [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
190 The purpose of Indexing is to provide a generalised version of
191 Vector ISA "Permute" instructions, such as VSX `vperm`. The
192 Indexing is abstracted out and may be applied to much more
193 than an element move/copy, and is not limited for example
194 to the number of bytes that can fit into a VSX register.
195 Indexing may be applied to LD/ST (even on Indexed LD/ST
196 instructions such as `sv.lbzx`), arithmetic operations,
197 extsw: there is no artificial limit.
199 The only major caveat is that the registers to be used as
200 Indices must not be modified by any instruction after Indexed Mode
201 is established, and neither must MAXVL be altered. Additionally,
202 no register used as an Index may exceed MAXVL-1.
205 these conditions results in `UNDEFINED` behaviour.
206 These conditions allow a Read-After-Write (RAW) Hazard to be created on
207 the entire range of Indices to be subsequently used, but a corresponding
208 Write-After-Read Hazard by any instruction that modifies the Indices
209 **does not have to be created**. Given the large number of registers
210 involved in Indexing this is a huge resource saving and reduction
211 in micro-architectural complexity. MAXVL is likewise
212 included in the RAW Hazards because it is involved in calculating
213 how many registers are to be considered Indices.
215 With these Hazard Mitigations in place, high-performance implementations
216 may read-cache the Indices from the point where a given `svindex` instruction
217 is called (or SVSHAPE SPRs - and MAXVL- directly altered).
219 The original motivation for Indexed REMAP was to mitigate the need to add
220 an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
221 a stand-alone instruction. Usually a Vector ISA would add a non-conflicting
222 variant (as in VSX `vperm`) but it is common to need to permute by source,
223 with the risk of conflict, that has to be resolved, for example, in AVX-512
226 Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
227 destinations), which on a superficial analysis may be perceived to be a
228 problem, until it is recalled that, firstly, Simple-V is designed specifically
229 to require Program Order to be respected, and that Matrix, DCT and FFT
230 all *already* critically depend on overlapping Reads/Writes: Matrix
231 uses overlapping registers as accumulators. Thus the Register Hazard
232 Management needed by Indexed REMAP *has* to be in place anyway.
234 The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
235 clearly that of the additional reading of the GPRs to be used as Indices,
236 plus the setup cost associated with creating those same Infices.
237 If any Deterministic REMAP can cover the required task, clearly it
238 is adviseable to use it instead.
240 *Programmer's note: some algorithms may require skipping of Indices exceeding
241 VL-1, not MAXVL-1. This may be achieved programmatically by performing
242 an `sv.cmp *BF,*RA,RB` where RA is the same GPRs used in the Indexed REMAP,
243 and RB contains the value of VL returned from `setvl`. The resultant
244 CR Fields may then be used as Predicate Masks to exclude those operations
245 with an Index exceeding VL-1.*
247 # REMAP area of SVSTATE
249 The following bits of the SVSTATE SPR are used for REMAP:
251 |32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
252 | -- | -- | -- | -- | -- | ----- | ------ |
253 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
255 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
256 mi0-2 apply to RA, RB, RC respectively, as input registers, and
257 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
258 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
259 SVSHAPE is actively applied or not.
261 * bit 0 of SVme indicates if mi0 is applied to RA / FRA
262 * bit 1 of SVme indicates if mi1 is applied to RB / FRB
263 * bit 2 of SVme indicates if mi2 is applied to RC / FRC
264 * bit 3 of SVme indicates if mo0 is applied to RT / FRT
265 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
266 (LD/ST-with-update has an implicit 2nd write register, RA)
268 # svremap instruction <a name="svremap"> </a>
270 There is also a corresponding SVRM-Form for the svremap
271 instruction which matches the above SPR:
273 svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
275 |0 |6 |11 |13 |15 |17 |19 |21 | 22.25 |26..31 |
276 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
277 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
279 # SHAPE Remapping SPRs
281 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
282 which have the same format.
284 Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
285 disabled: the register's elements are a linear (1D) vector.
287 |31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
288 |---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
289 |0b00 |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
290 |0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
291 |0b01 |submode|offset| invxyz | submode2| rsvd |rsvd |xdimsz|DCT/FFT|
292 |0b10 | | | | | | | |rsvd |
293 |0b11 | | | | | | | |rsvd |
295 mode sets different behaviours (straight matrix multiply, FFT, DCT).
297 * **mode=0b00** sets straight Matrix Mode
298 * **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
299 * **mode=0b01** sets "FFT/DCT" mode and activates submodes
303 submode2=0 is for FFT. For FFT submode the following schedules may be
306 * **submode=0b00** selects the ``j`` offset of the innermost for-loop
308 * **submode=0b10** selects the ``j+halfsize`` offset of the innermost for-loop
310 * **submode=0b11** selects the ``k`` of exptable (which coefficient)
312 When submode2 is 1 or 2, for DCT inner butterfly submode the following
313 schedules may be selected. When submode2 is 1, additional bit-reversing
316 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
318 * **submode=0b010** selects the ``j+halfsize`` offset of the innermost for-loop,
319 in reverse-order, in-place
320 * **submode=0b10** selects the ``ci`` count of the innermost for-loop,
321 useful for calculating the cosine coefficient
322 * **submode=0b11** selects the ``size`` offset of the outermost for-loop,
323 useful for the cosine coefficient ``cos(ci + 0.5) * pi / size``
325 When submode2 is 3 or 4, for DCT outer butterfly submode the following
326 schedules may be selected. When submode is 3, additional bit-reversing
329 * **submode=0b00** selects the ``j`` offset of the innermost for-loop,
330 * **submode=0b01** selects the ``j+1`` offset of the innermost for-loop,
334 In Matrix Mode, skip allows dimensions to be skipped from being included
335 in the resultant output index. this allows sequences to be repeated:
336 ```0 0 0 1 1 1 2 2 2 ...``` or in the case of skip=0b11 this results in
337 modulo ```0 1 2 0 1 2 ...```
339 * **skip=0b00** indicates no dimensions to be skipped
340 * **skip=0b01** sets "skip 1st dimension"
341 * **skip=0b10** sets "skip 2nd dimension"
342 * **skip=0b11** sets "skip 3rd dimension"
344 invxyz will invert the start index of each of x, y or z. If invxyz[0] is
345 zero then x-dimensional counting begins from 0 and increments, otherwise
346 it begins from xdimsz-1 and iterates down to zero. Likewise for y and z.
348 offset will have the effect of offsetting the result by ```offset``` elements:
351 GPR(RT + remap(i) + SVSHAPE.offset) = ....
353 this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
354 bear in mind that unlike a static compiler SVSHAPE.offset may
355 be set dynamically at runtime.
357 xdimsz, ydimsz and zdimsz are offset by 1, such that a value of 0 indicates
358 that the array dimensionality for that dimension is 1. any dimension
359 not intended to be used must have its value set to 0 (dimensionality
360 of 1). A value of xdimsz=2 would indicate that in the first dimension
361 there are 3 elements in the array. For example, to create a 2D array
362 X,Y of dimensionality X=3 and Y=2, set xdimsz=2, ydimsz=1 and zdimsz=0
364 The format of the array is therefore as follows:
366 array[xdimsz+1][ydimsz+1][zdimsz+1]
368 However whilst illustrative of the dimensionality, that does not take the
369 "permute" setting into account. "permute" may be any one of six values
370 (0-5, with values of 6 and 7 indicating "Indexed" Mode). The table
371 below shows how the permutation dimensionality order works:
373 | permute | order | array format |
374 | ------- | ----- | ------------------------ |
375 | 000 | 0,1,2 | (xdim+1)(ydim+1)(zdim+1) |
376 | 001 | 0,2,1 | (xdim+1)(zdim+1)(ydim+1) |
377 | 010 | 1,0,2 | (ydim+1)(xdim+1)(zdim+1) |
378 | 011 | 1,2,0 | (ydim+1)(zdim+1)(xdim+1) |
379 | 100 | 2,0,1 | (zdim+1)(xdim+1)(ydim+1) |
380 | 101 | 2,1,0 | (zdim+1)(ydim+1)(xdim+1) |
381 | 110 | 0,1 | Indexed (xdim+1)(ydim+1) |
382 | 111 | 1,0 | Indexed (ydim+1)(xdim+1) |
384 In other words, the "permute" option changes the order in which
385 nested for-loops over the array would be done. See executable
386 python reference code for further details.
388 *Note: permute=0b110 and permute=0b111 enable Indexed REMAP Mode,
391 With all these options it is possible to support in-place transpose,
392 in-place rotate, Matrix Multiply and Convolutions, without being
393 limited to Power-of-Two dimension sizes.
397 Indexed Mode activates reading of the element indices from the GPR
398 and includes optional limited 2D reordering.
399 In its simplest form (without elwidth overrides or other modes):
403 return GPR((SVSHAPE.SVGPR<<1)+i+SVSHAPE.offset)
406 element_result = ....
407 GPR(RT + indexed_remap(i)) = element_result
410 With element-width overrides included, and using the pseudocode
411 from the SVP64 [[sv/svp64/appendix#elwidth]] elwidth section
416 svreg = SVSHAPE.SVGPR << 1
417 srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
418 offs = SVSHAPE.offset
419 return get_polymorphed_reg(svreg, srcwid, i) + offs
422 element_result = ....
423 rt_idx = indexed_remap(i)
424 set_polymorphed_reg(RT, destwid, rt_idx, element_result)
427 Matrix-style reordering still applies to the indices, except limited
428 to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
429 (Y,X). Only one dimension may optionally be skipped. Inversion of either
430 X or Y or both is possible. Pseudocode for Indexed Mode (including elwidth
431 overrides) may be written in terms of Matrix Mode, specifically
432 purposed to ensure that the 3rd dimension (Z) has no effect:
435 def index_remap(ISHAPE, i):
436 MSHAPE.skip = 0b0 || ISHAPE.sk1
437 MSHAPE.invxyz = 0b0 || ISHAPE.invxy
438 MSHAPE.xdimsz = ISHAPE.xdimsz
439 MSHAPE.ydimsz = ISHAPE.ydimsz
440 MSHAPE.zdimsz = 0 # disabled
441 if ISHAPE.permute = 0b110 # 0,1
442 MSHAPE.permute = 0b000 # 0,1,2
443 if ISHAPE.permute = 0b111 # 1,0
444 MSHAPE.permute = 0b010 # 1,0,2
445 el_idx = remap_matrix(MSHAPE, i)
446 svreg = ISHAPE.SVGPR << 1
447 srcwid = elwid_to_bitwidth(ISHAPE.elwid)
449 return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
452 The most important observation above is that the Matrix-style
453 remapping occurs first and the Index lookup second. Thus it
454 becomes possible to perform in-place Transpose of Indices which
455 may have been costly to set up or costly to duplicate
456 (waste register file space).
457 # svshape instruction <a name="svshape"> </a>
459 `svshape` is a convenience instruction that reduces instruction
460 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
461 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
462 including VL and MAXVL. Using `svshape` therefore does not also
465 Form: SVM-Form SV "Matrix" Form (see [[isatables/fields.text]])
467 svshape SVxd,SVyd,SVzd,SVRM,vf
469 | 0.5|6.10 |11.15 |16..20 | 21..25 | 25 | 26..31| name |
470 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
471 |OPCD| SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
475 * **SVxd** - SV REMAP "xdim"
476 * **SVyd** - SV REMAP "ydim"
477 * **SVzd** - SV REMAP "zdim"
478 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
479 * **vf** - sets "Vertical-First" mode
480 * **XO** - standard 6-bit XO field
482 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
483 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
485 | SVRM | Remap Mode description |
487 | 0b0000 | Matrix 1/2/3D |
488 | 0b0001 | FFT Butterfly |
489 | 0b0010 | DCT Inner butterfly, pre-calculated coefficients |
490 | 0b0011 | DCT Outer butterfly |
491 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
492 | 0b0101 | DCT COS table index generation |
493 | 0b0110 | DCT half-swap |
494 | 0b0111 | reserved |
495 | 0b1000 | reserved |
496 | 0b1001 | reserved |
497 | 0b1010 | iDCT Inner butterfly, pre-calculated coefficients |
498 | 0b1011 | iDCT Outer butterfly |
499 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
500 | 0b1101 | iDCT COS table index generation |
501 | 0b1110 | iDCT half-swap |
502 | 0b1111 | FFT half-swap |
504 Examples showing how all of these Modes operate exists in the online
505 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD)
506 and the full pseudocode setting up all SPRs
507 is in the [[openpower/isa/simplev]] page.
509 In Indexed Mode, there are only 5 bits available to specify the GPR
510 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
511 5 bits are given in the `SVxd` field: the bottom two implicit bits
512 will be zero (`SVxd || 0b00`).
514 `svshape` has *limited applicability* due to being a 32-bit instruction.
515 The full capability of SVSHAPE SPRs may be accessed by directly writing
516 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
517 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
518 instruction, `psvshape`, may extend the capability here.
520 # svindex instruction <a name="svindex"> </a>
522 `svindex` is a convenience instruction that reduces instruction
523 count for Indexed REMAP Mode. It sets up
524 (overwrites) all required SVSHAPE SPRs and can modify the REMAP
525 SPR as well. The relevant SPRs *may* be directly programmed with
526 `mtspr` however it is laborious to do so: svindex saves instructions
527 covering much of Indexed REMAP capability.
529 Form: SVI-Form SV "Indexed" Form (see [[isatables/fields.text]])
531 svindex SVG,rmm,SVd,ew,yx,mr,sk
533 | 0.5|6.10 |11.15 |16.20 | 21..25 | 26..31| name | Form |
534 | -- | -- | --- | ---- | ----------- | ------| -------- | ---- |
535 |OPCD| SVG | rmm | SVd | ew/yx/mm/sk | XO | svindex | SVI-Form |
539 * **SVd** - SV REMAP x/y dim
540 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
542 * **ew** - sets element width override on the Indices
543 * **SVG** - GPR SVG<<2 to be used for Indexing
544 * **yx** - 2D reordering to be used if yx=1
545 * **mm** - mask mode. determines how `rmm` is interpreted.
546 * **sk** - Dimension skipping enabled
547 * **XO** - standard 6-bit XO field
549 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
550 "off-by-one". In the assembler
551 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
553 *Note: when `yx=1,sk=0` the second dimension is calculated as
558 * `rmm`, like REMAP.SVme, has bit 0
559 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
560 bit 3 to mo0 and bit 4 to mi1
561 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
562 * for each bit set in the 5-bit `rmm`, in order, the first
563 as-yet-unset SVSHAPE will be updated
564 with the other operands in the instruction, and the REMAP
566 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
567 * SVSTATE persistence bit is cleared
568 * No other alterations to SVSTATE are carried out
570 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
571 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
572 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
573 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
575 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
576 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
577 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
579 Rough algorithmic form:
581 marray = [mi0, mi1, mi2, mo0, mo1]
584 if not rmm[bit]: continue
586 SVSTATE{marray[bit]} = idx
587 idx = (idx+1) modulo 4
591 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
592 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
594 * only the selected SVSHAPE is overwritten
595 * only the relevant bits in the REMAP area of SVSTATE are updated
596 * REMAP persistence bit is set.
598 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
599 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
600 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
603 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
604 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
605 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
608 Rough algorithmic form:
610 marray = [mi0, mi1, mi2, mo0, mo1]
614 SVSTATE{marray[bit]} = idx
617 In essence, `mm=0` is intended for use to set as much of the
618 REMAP State SPRs as practical with a single instruction,
619 whilst `mm=1` is intended to be a little more refined.
623 * **Disable 2D mapping**: to only perform Indexing without
624 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
626 * **Modulo 1D mapping**: to perform Indexing cycling through the
627 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
628 no requirement to set VL equal to a multiple of N.
629 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
630 `xdim=M,ydim=CEIL(MAXVL/M)`.
632 Beyond these mappings it becomes necessary to write directly to
633 the SVSTATE SPRs manually.
638 * investigate https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6879380/#!po=19.6429
639 in https://bugs.libre-soc.org/show_bug.cgi?id=653
640 * UTF-8 <https://bugs.libre-soc.org/show_bug.cgi?id=794>
642 * Cross-Product REMAP (actually, skew Matrix: https://en.m.wikipedia.org/wiki/Skew-symmetric_matrix)