-[[!tag standards]]
-
# REMAP <a name="remap" />
+<!-- hide -->
* <https://bugs.libre-soc.org/show_bug.cgi?id=143> matrix multiply
* <https://bugs.libre-soc.org/show_bug.cgi?id=867> add svindex
* <https://bugs.libre-soc.org/show_bug.cgi?id=885> svindex in simulator
* see [[sv/remap/appendix]] for examples and usage
* see [[sv/propagation]] for a future way to apply REMAP
* [[remap/discussion]]
-
-REMAP is an advanced form of Vector "Structure Packing" that
-provides hardware-level support for commonly-used *nested* loop patterns.
-For more general reordering an Indexed REMAP mode is available.
-
-REMAP allows the usual vector loop `0..VL-1` to be "reshaped" (re-mapped)
-from a linear form to a 2D or 3D transposed form, or "offset" to permit
-arbitrary access to elements (when elwidth overrides are used),
-independently on each Vector src or dest
-register.
-
-The initial primary motivation of REMAP was for Matrix Multiplication, reordering of sequential
-data in-place: in-place DCT and FFT were easily justified given the
-high usage in Computer Science.
-Four SPRs are provided which may be applied to any GPR, FPR or CR Field
-so that for example a single FMAC may be
-used in a single loop to perform 5x3 times 3x4 Matrix multiplication,
+<!-- show -->
+
+REMAP is an advanced form of Vector "Structure Packing" that provides
+hardware-level support for commonly-used *nested* loop patterns that would
+otherwise require full inline loop unrolling. For more general reordering
+an Indexed REMAP mode is available (a RISC-paradigm
+abstracted analog to `xxperm`).
+
+REMAP allows the usual sequential vector loop `0..VL-1` to be "reshaped"
+(re-mapped) from a linear form to a 2D or 3D transposed form, or "offset"
+to permit arbitrary access to elements (when elwidth overrides are
+used), independently on each Vector src or dest register. Aside from
+Indexed REMAP this is entirely Hardware-accelerated reordering and
+consequently not costly in terms of register access. It will however
+place a burden on Multi-Issue systems but no more than if the equivalent
+Scalar instructions were explicitly loop-unrolled without SVP64, and
+some advanced implementations may even find the Deterministic nature of
+the Scheduling to be easier on resources.
+
+The initial primary motivation of REMAP was for Matrix Multiplication,
+reordering of sequential data in-place: in-place DCT and FFT were
+easily justified given the exceptionally high usage in Computer Science.
+Four SPRs are provided which may be applied to any GPR, FPR or CR Field so
+that for example a single FMAC may be used in a single hardware-controlled
+100% Deterministic loop to perform 5x3 times 3x4 Matrix multiplication,
generating 60 FMACs *without needing explicit assembler unrolling*.
-Additional uses include regular "Structure Packing"
-such as RGB pixel data extraction and reforming.
-
+Additional uses include regular "Structure Packing" such as RGB pixel
+data extraction and reforming (although less costly vec2/3/4 reshaping
+is achievable with `PACK/UNPACK`).
+
+Even once designed as an independent RISC-paradigm abstraction system
+it was realised that Matrix REMAP could be applied to min/max instructions to
+achieve Floyd-Warshall Graph computations, or to AND/OR Ternary
+bitmanipulation to compute Warshall Transitive Closure, or
+to perform Cryptographic Matrix operations with Galois Field
+variants of Multiply-Accumulate and many more uses expected to be
+discovered. This *without
+adding actual explicit Vector opcodes for any of the same*.
+
+Thus it should be very clear:
REMAP, like all of SV, is abstracted out, meaning that unlike traditional
Vector ISAs which would typically only have a limited set of instructions
-that can be structure-packed (LD/ST typically), REMAP may be applied to
-literally any instruction: CRs, Arithmetic, Logical, LD/ST, anything.
-
-Note that REMAP does not *directly* apply to sub-vector elements: that
-is what swizzle is for. Swizzle *can* however be applied to the same
-instruction as REMAP. As explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack EXTRA Mode bits
-can extend down into Sub-vector elements to perform vec2/vec3/vec4
-sequential reordering, but even here, REMAP is not extended down to
-the actual sub-vector elements themselves.
+that can be structure-packed (LD/ST and Move operations
+being the most common), REMAP may be applied to
+literally any instruction: CRs, Arithmetic, Logical, LD/ST, even
+Vectorised Branch-Conditional.
+
+When SUBVL is greater than 1 a given group of Subvector
+elements are kept together: effectively the group becomes the
+element, and with REMAP applying to elements
+(not sub-elements) each group is REMAPed together.
+Swizzle *can* however be applied to the same
+instruction as REMAP, providing re-sequencing of
+Subvector elements which REMAP cannot. Also as explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack Mode bits
+can extend down into Sub-vector elements to influence vec2/vec3/vec4
+sequential reordering, but even here, REMAP reordering is not *individually*
+extended down to the actual sub-vector elements themselves.
+This keeps the relevant Predicate Mask bit applicable to the Subvector
+group, just as it does when REMAP is not active.
In its general form, REMAP is quite expensive to set up, and on some
-implementations may introduce
-latency, so should realistically be used only where it is worthwhile.
-Commonly-used patterns such as Matrix Multiply, DCT and FFT have
-helper instruction options which make REMAP easier to use.
+implementations may introduce latency, so should realistically be used
+only where it is worthwhile. Given that even with latency the fact
+that up to 127 operations can be Deterministically issued (from a single
+instruction) it should be clear that REMAP should not be dismissed
+for *possible* latency alone. Commonly-used patterns such as Matrix
+Multiply, DCT and FFT have helper instruction options which make REMAP
+easier to use.
+
+*Future specification note: future versions of the REMAP Management instructions
+will extend to EXT1xx Prefixed variants. This will overcome some of the limitations
+present in the 32-bit variants of the REMAP Management instructions that at
+present require direct writing to SVSHAPE0-3 SPRs. Additional
+REMAP Modes may also be introduced at that time.*
There are four types of REMAP:
* **FFT/DCT**, with full triple-loop in-place support: limited to
Power-2 RADIX
* **Indexing**, for any general-purpose reordering, also includes
- limited 2D reshaping.
+ limited 2D reshaping as well as Element "offsetting".
* **Parallel Reduction**, for scheduling a sequence of operations
in a Deterministic fashion, in a way that may be parallelised,
to reduce a Vector down to a single value.
designed to be incorporated in between the Decode and Issue phases,
directly into Register Hazard Management.
+As long as the SVSHAPE SPRs
+are not written to directly, Hardware may treat REMAP as 100%
+Deterministic: all REMAP Management instructions take static
+operands (no dynamic register operands)
+with the exception of Indexed Mode, and even then
+Architectural State is permitted to assume that the Indices
+are cacheable from the point at which the `svindex` instruction
+is executed.
+
Parallel Reduction is unusual in that it requires a full vector array
of results (not a scalar) and uses the rest of the result Vector for
the purposes of storing intermediary calculations. As these intermediary
results are Deterministically computed they may be useful.
Additionally, because the intermediate results are always written out
it is possible to service Precise Interrupts without affecting latency
-(a common limitation of Vector ISAs).
+(a common limitation of Vector ISAs implementing explicit
+Parallel Reduction instructions, because their Architectural State cannot
+hold the partial results).
+
+## Basic principle
-# Basic principle
+The following illustrates why REMAP was added.
* normal vector element read/write of operands would be sequential
(0 1 2 3 ....)
accessing elements in alternative sequences (0 3 6 1 4 7 ...)
* normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
with this. both are expensive (copy large vectors, spill through memory)
- and very few Packed SIMD ISAs cope with non-Power-2.
+ and very few Packed SIMD ISAs cope with non-Power-2
+ (Duplicate-data inline-loop-unrolling is the costly solution)
* REMAP **redefines** the order of access according to set
(Deterministic) "Schedules".
-* The Schedules are not at all restricted to power-of-two boundaries
+* Matrix Schedules are not at all restricted to power-of-two boundaries
making it unnecessary to have for example specialised 3x4 transpose
instructions of other Vector ISAs.
+* DCT and FFT REMAP are RADIX-2 limited but this is the case in existing Packed/Predicated
+ SIMD ISAs anyway (and Bluestein Convolution is typically deployed to
+ solve that).
Only the most commonly-used algorithms in computer science have REMAP
support, due to the high cost in both the ISA and in hardware. For
arbitrary remapping the `Indexed` REMAP may be used.
-# Example Usage
+## Example Usage
* `svshape` to set the type of reordering to be applied to an
otherwise usual `0..VL-1` hardware for-loop
matrix to create
a 5x4 result:
- svshape 5, 4, 3, 0, 0
- svremap 15, 1, 2, 3, 0, 0, 0, 0
- sv.fmadds *0, *8, *16, *0
+```
+ svshape 5,4,3,0,0 # Outer Product 5x4 by 4x3
+ svremap 15,1,2,3,0,0,0,0 # link Schedule to registers
+ sv.fmadds *0,*32,*64,*0 # 60 FMACs get executed here
+```
* svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
* svremap activates four out of five registers RA RB RC RT RS (15)
- RC to use SVSHAPE3
- RT to use SVSHAPE0
- RS Remapping to not be activated
-* sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
+* sv.fmadds has vectors RT=0, RA=32, RB=64, RC=0
* With REMAP being active each register's element index is
*independently* transformed using the specified SHAPEs.
Thus the Vector Loop is arranged such that the use of
the multiply-and-accumulate instruction executes precisely the required
-Schedule to perform an in-place in-registers Matrix Multiply with no
+Schedule to perform an in-place in-registers Outer Product
+Matrix Multiply with no
need to perform additional Transpose or register copy instructions.
The example above may be executed as a unit test and demo,
[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)
-
-# REMAP types
+
+*Hardware Architectural note: with the Scheduling applying as a Phase between
+Decode and Issue in a Deterministic fashion the Register Hazards may be
+easily computed and a standard Out-of-Order Micro-Architecture exploited to good
+effect. Even an In-Order system may observe that for large Outer Product
+Schedules there will be no stalls, but if the Matrices are particularly
+small size an In-Order system would have to stall, just as it would if
+the operations were loop-unrolled without Simple-V. Thus: regardless
+of the Micro-Architecture the Hardware Engineer should first consider
+how best to process the exact same equivalent loop-unrolled instruction
+stream.*
+
+## Horizontal-Parallelism Hint
+
+`SVSTATE.hphint` is an indicator to hardware of how many elements are 100%
+fully independent. Hardware is permitted to assume that groups of elements
+up to `hphint` in size need not have Register (or Memory) Hazards created
+between them (including when `hphint > VL`).
+
+If care is not taken in setting `hphint` correctly it may wreak havoc.
+For example Matrix Outer Product relies on the innermost loop computations
+being independent. If `hphint` is set to greater than the Outer Product
+depth then data corruption is guaranteed to occur.
+
+Likewise on FFTs it is assumed that each layer of the RADIX2 triple-loop
+is independent, but that there is strict *inter-layer* Register Hazards.
+Therefore if `hphint` is set to greater than the RADIX2 width of the FFT,
+data corruption is guaranteed.
+
+Thus the key message is that setting `hphint` requires in-depth knowledge
+of the REMAP Algorithm Schedules, given in the Appendix.
+
+## REMAP types
This section summarises the motivation for each REMAP Schedule
and briefly goes over their characteristics and limitations.
Further details on the Deterministic Precise-Interruptible algorithms
used in these Schedules is found in the [[sv/remap/appendix]].
-## Matrix (1D/2D/3D shaping)
+### Matrix (1D/2D/3D shaping)
Matrix Multiplication is a huge part of High-Performance Compute,
and 3D.
(5x7, 3x5) become deeply problematic to unroll.
Even traditional Scalable Vector ISAs have issues with Matrices, often
-having to perform data Transpose by pushing out through Memory and back,
+having to perform data Transpose by pushing out through Memory and back
+(costly),
or computing Transposition Indices (costly) then copying to another
Vector (costly).
Also given that it is in-registers only at present some care has to be
taken on regfile resource utilisation. However it is perfectly possible
to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
-the usual 6-level large Matrix Multiply, without the usual difficulties
-associated with SIMD.
+the usual 6-level "Tiled" large Matrix Multiply, without the usual
+difficulties associated with SIMD.
Also the `svshape` instruction only provides access to part of the
Matrix REMAP capability. Rotation and mirroring need to be done by
programming the SVSHAPE SPRs directly, which can take a lot more
-instructions.
+instructions. Future versions of SVP64 will include EXT1xx prefixed
+variants (`psvshape`) which provide more comprehensive capacity and
+mitigate the need to write direct to the SVSHAPE SPRs.
-## FFT/DCT Triple Loop
+### FFT/DCT Triple Loop
DCT and FFT are some of the most astonishingly used algorithms in
Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
to compute arbitrary length is demonstrated by
[Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
-## Indexed
+### Indexed
The purpose of Indexing is to provide a generalised version of
Vector ISA "Permute" instructions, such as VSX `vperm`. The
how many registers are to be considered Indices.
With these Hazard Mitigations in place, high-performance implementations
-may read-cache the Indices from the point where a given `svindex` instruction
-is called (or SVSHAPE SPRs - and MAXVL- directly altered).
+may read-cache the Indices at the point where a given `svindex` instruction
+is called (or SVSHAPE SPRs - and MAXVL - directly altered) by issuing
+background GPR register file reads whilst other instructions are being
+issued and executed.
The original motivation for Indexed REMAP was to mitigate the need to add
an expensive `mv.x` to the Scalar ISA, which was likely to be rejected as
-a stand-alone instruction. Usually a Vector ISA would add a non-conflicting
+a stand-alone instruction
+(`GPR(RT) <- GPR(GPR(RA))`). Usually a Vector ISA would add a non-conflicting
variant (as in VSX `vperm`) but it is common to need to permute by source,
with the risk of conflict, that has to be resolved, for example, in AVX-512
with `conflictd`.
uses overlapping registers as accumulators. Thus the Register Hazard
Management needed by Indexed REMAP *has* to be in place anyway.
+*Programmer's Note: `hphint` may be used to help hardware identify
+parallelism opportunities but it is critical to remember that the
+groupings are by `FLOOR(step/MAXVL)` not `FLOOR(REMAP(step)/MAXVL)`.*
+
The cost compared to Matrix and other REMAPs (and Pack/Unpack) is
clearly that of the additional reading of the GPRs to be used as Indices,
plus the setup cost associated with creating those same Indices.
CR Fields may then be used as Predicate Masks to exclude those operations
with an Index exceeding VL-1.*
-## Parallel Reduction
+### Parallel Reduction
Vector Reduce Mode issues a deterministic tree-reduction schedule to the underlying micro-architecture. Like Scalar reduction, the "Scalar Base"
(Power ISA v3.0B) operation is leveraged, unmodified, to give the
-*appearance* and *effect* of Reduction.
+*appearance* and *effect* of Reduction. Parallel Reduction is not limited
+to Power-of-two but is limited as usual by the total number of
+element operations (127) as well as available register file size.
In Horizontal-First Mode, Vector-result reduction **requires**
the destination to be a Vector, which will be used to store
-intermediary results.
+intermediary results, in order to achieve a correct final
+result.
Given that the tree-reduction schedule is deterministic,
Interrupts and exceptions
can therefore also be precise. The final result will be in the first
non-predicate-masked-out destination element, but due again to
the deterministic schedule programmers may find uses for the intermediate
-results.
+results, even for non-commutative Defined Word operations.
When Rc=1 a corresponding Vector of co-resultant CRs is also
-created. No special action is taken: the result and its CR Field
+created. No special action is taken: the result *and its CR Field*
are stored "as usual" exactly as all other SVP64 Rc=1 operations.
Note that the Schedule only makes sense on top of certain instructions:
Reduction, nothing is prohibited:
the results of execution on an unsuitable instruction may simply
not make sense. With care, even 3-input instructions (madd, fmadd, ternlogi)
-may be used.
+may be used, and whilst it is down to the Programmer to walk through the
+process the Programmer can be confident that the Parallel-Reduction is
+guaranteed 100% Deterministic.
Critical to note regarding use of Parallel-Reduction REMAP is that,
exactly as with all REMAP Modes, the `svshape` instruction *requests*
Move operations are **not** included in the Schedule. This means that
the Schedule leaves the final (scalar) result in the first-non-masked
element of the Vector used. With the predicate mask being dynamic
-(but deterministic) this result could be anywhere.
+(but deterministic) at a superficial glance it seems this result
+could be anywhere.
If that result is needed to be moved to a (single) scalar register
then a follow-up `sv.mv/sm=predicate rt, *ra` instruction will be
first element with a predicate bit set.
In either case the result is in the element with the first bit set in
-the predicate mask.
+the predicate mask. Thus, no move/copy *within the Reduction itself* was needed.
-For *some* implementations
+Programmer's Note: For *some* hardware implementations
the vector-to-scalar copy may be a slow operation, as may the Predicated
Parallel Reduction itself.
It may be better to perform a pre-copy
of the values, compressing them (VREDUCE-style) into a contiguous block,
which will guarantee that the result goes into the very first element
of the destination vector, in which case clearly no follow-up
-vector-to-scalar MV operation is needed.
+predicated vector-to-scalar MV operation is needed. A VREDUCE effect
+is achieved by setting just a source predicate mask on Twin-Predicated
+operations.
**Usage conditions**
The simplest usage is to perform an overwrite, specifying all three
register operands the same.
+```
svshape parallelreduce, 6
sv.add *8, *8, *8
+```
The Reduction Schedule will issue the Parallel Tree Reduction spanning
registers 8 through 13, by adjusting the offsets to RT, RA and RB as
intermediary computations will be written to: the remaining elements
will **not** be overwritten and will **not** be zero'd.
+```
svshape parallelreduce, 6
sv.add *0, *8, *8
+```
However it is critical to note that if the source and destination are
not the same then the trick of using a follow-up vector-scalar MV will
not work.
-## Sub-Vector Horizontal Reduction
-
-Note that when SVM is clear and SUBVL!=1 a Parallel Reduction is performed
-on all first Subvector elements, followed by another separate independent
-Parallel Reduction on all the second Subvector elements and so on.
-
- for selectsubelement in (x,y,z,w):
- parallelreduce(0..VL-1, selectsubelement)
+### Sub-Vector Horizontal Reduction
-By contrast, when SVM is set and SUBVL!=1, a Horizontal
-Subvector mode is enabled, applying the Parallel Reduction
-Algorithm to the Subvector Elements. The Parallel Reduction
-is independently applied VL times, to each group of Subvector
-elements. Bear in mind that predication is never applied down
-into individual Subvector elements, but will be applied
-to select whether the *entire* Parallel Reduction on each
-group is performed or not.
+To achieve Sub-Vector Horizontal Reduction, Pack/Unpack should be enabled,
+which will turn the Schedule around such that issuing of the Scalar
+Defined Words is done with SUBVL looping as the inner loop not the
+outer loop. Rc=1 with Sub-Vectors (SUBVL=2,3,4) is `UNDEFINED` behaviour.
- for (i = 0; i < VL; i++)
- if (predval & 1<<i) # predication
- el = element[i]
- parallelreduction([el.x, el.y, el.z, el.w])
+*Programmer's Note: Overwrite Parallel Reduction with Sub-Vectors
+will clearly result in data corruption. It may be best to perform
+a Pack/Unpack Transposing copy of the data first*
-Note that as this is a Parallel Reduction, for best results
-it should be an overwrite operation, where the result for
-the Horizontal Reduction of each Subvector will be in the
-first Subvector element.
-Also note that use of Rc=1 is `UNDEFINED` behaviour.
-
-In essence what is happening here is that Structure Packing is being
-combined with Parallel Reduction. If the Subvector elements may be
-laid out as a 2D matrix, with the Subvector elements on rows,
-and Parallel Reduction is applied per row, then if `SVM` is **clear**
-the Matrix is transposed (like Pack/Unpack)
-before still applying the Parallel Reduction to the **row**.
-
-# Determining Register Hazards
+## Determining Register Hazards
For high-performance (Multi-Issue, Out-of-Order) systems it is critical
to be able to statically determine the extent of Vectors in order to
The problems come when REMAP is enabled. Indexed REMAP must instead
use `MAXVL` as the earliest (simplest)
-batch-level Hazard Reservation indicator,
+batch-level Hazard Reservation indicator (after taking element-width
+overriding on the Index source into consideration),
but Matrix, FFT and Parallel Reduction must all use completely different
schemes. The reason is that VL is used to step through the total
-number of *operations*, not the number of registers. The "Saving Grace"
-is that all of the REMAP Schedules are Deterministic.
+number of *operations*, not the number of registers.
+The "Saving Grace" is that all of the REMAP Schedules are 100% Deterministic.
Advance-notice Parallel computation and subsequent cacheing
of all of these complex Deterministic REMAP Schedules is
with varying degrees of refinement possible at correspondingly
increasing levels of complexity in hardware.
-# REMAP area of SVSTATE
+A reminder: when Rc=1 each result register (element) has an associated
+co-result CR Field (one per result element). Thus above when determining
+the Write-Hazards for result registers the corresponding Write-Hazards for the
+corresponding associated co-result CR Field must not be forgotten, *including* when
+Predication is used.
+
+## REMAP area of SVSTATE SPR
The following bits of the SVSTATE SPR are used for REMAP:
-|32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
-| -- | -- | -- | -- | -- | ----- | ------ |
-|mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
+```
+ |32:33|34:35|36:37|38:39|40:41| 42:46 | 62 |
+ | -- | -- | -- | -- | -- | ----- | ------ |
+ |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
+```
mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
mi0-2 apply to RA, RB, RC respectively, as input registers, and
likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
-SVSHAPE is actively applied or not.
+SVSHAPE is actively applied or not, and if so, to which registers.
-* bit 0 of SVme indicates if mi0 is applied to RA / FRA
-* bit 1 of SVme indicates if mi1 is applied to RB / FRB
-* bit 2 of SVme indicates if mi2 is applied to RC / FRC
-* bit 3 of SVme indicates if mo0 is applied to RT / FRT
-* bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
+* bit 4 of SVme indicates if mi0 is applied to source RA / FRA / BA / BFA / RT / FRT
+* bit 3 of SVme indicates if mi1 is applied to source RB / FRB / BB
+* bit 2 of SVme indicates if mi2 is applied to source RC / FRC / BC
+* bit 1 of SVme indicates if mo0 is applied to result RT / FRT / BT / BF
+* bit 0 of SVme indicates if mo1 is applied to result Effective Address / FRS / RS
(LD/ST-with-update has an implicit 2nd write register, RA)
-# svremap instruction <a name="svremap"> </a>
+The "persistence" bit if set will result in all Active REMAPs being applied
+indefinitely.
-There is also a corresponding SVRM-Form for the svremap
-instruction which matches the above SPR:
+-----------
- svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
+\newpage{}
-|0 |6 |11 |13 |15 |17 |19 |21 | 22.25 |26..31 |
+# svremap instruction <a name="svremap"> </a>
+
+SVRM-Form:
+
+|0 |6 |11 |13 |15 |17 |19 |21 | 22:25 |26:31 |
| -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
| PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
+* svremap SVme,mi0,mi1,mi2,mo0,mo1,pst
+
+Pseudo-code:
+
+```
+ # registers RA RB RC RT EA/FRS SVSHAPE0-3 indices
+ SVSTATE[32:33] <- mi0
+ SVSTATE[34:35] <- mi1
+ SVSTATE[36:37] <- mi2
+ SVSTATE[38:39] <- mo0
+ SVSTATE[40:41] <- mo1
+ # enable bit for RA RB RC RT EA/FRS
+ SVSTATE[42:46] <- SVme
+ # persistence bit (applies to more than one instruction)
+ SVSTATE[62] <- pst
+```
+
+Special Registers Altered:
+
+```
+ SVSTATE
+```
+
+`svremap` determines the relationship between registers and SVSHAPE SPRs.
+The bitmask `SVme` determines which registers have a REMAP applied, and mi0-mo1
+determine which shape is applied to an activated register. the `pst` bit if
+cleared indicated that the REMAP operation shall only apply to the immediately-following
+instruction. If set then REMAP remains permanently enabled until such time as it is
+explicitly disabled, either by `setvl` setting a new MAXVL, or with another
+`svremap` instruction. `svindex` and `svshape2` are also capable of setting or
+clearing persistence, as well as partially covering a subset of the capability of
+`svremap` to set register-to-SVSHAPE relationships.
+
+Programmer's Note: applying non-persistent `svremap` to an instruction that has
+no REMAP enabled or is a Scalar operation will obviously have no effect but
+the bits 32 to 46 will at least have been set in SVSTATE. This may prove useful
+when using `svindex` or `svshape2`.
+
+Hardware Architectural Note: when persistence is not set it is critically important
+to treat the `svremap` and the following SVP64 instruction as an indivisible fused operation.
+*No state* is stored in the SVSTATE SPR in order to allow continuation should an
+Interrupt occur between the two instructions. Thus, Interrupts must be prohibited
+from occurring or other workaround deployed. When persistence is set this issue
+is moot.
+
+It is critical to note that if persistence is clear then `svremap` is the *only* way
+to activate REMAP on any given (following) instruction. If persistence is set however then
+**all** SVP64 instructions go through REMAP as long as `SVme` is non-zero.
+
+-------------
+
+\newpage{}
+
# SHAPE Remapping SPRs
There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
Shape is 32-bits. When SHAPE is set entirely to zeros, remapping is
disabled: the register's elements are a linear (1D) vector.
-|31.30|29..28 |27..24| 23..21 | 20..18 | 17..12 |11..6 |5..0 | Mode |
-|---- |------ |------| ------ | ------- | ------- |----- |----- | ----- |
-|0b00 |skip |offset| invxyz | permute | zdimsz |ydimsz|xdimsz|Matrix |
-|0b00 |elwidth|offset|sk1/invxy|0b110/0b111|SVGPR|ydimsz|xdimsz|Indexed|
-|0b01 |submode|offset| invxyz | submode2| zdimsz |mode |xdimsz|DCT/FFT|
-|0b10 |submode|offset| invxyz | rsvd | rsvd |rsvd |xdimsz|Preduce|
-|0b11 | | | | | | | |rsvd |
+|0:5 |6:11 | 12:17 | 18:20 | 21:23 |24:27 |28:29 |30:31| Mode |
+|----- |----- | ------- | ------- | ------ |------|------ |---- | ----- |
+|xdimsz|ydimsz| zdimsz | permute | invxyz |offset|skip |mode |Matrix |
+|xdimsz|ydimsz|SVGPR | 11/ |sk1/invxy|offset|elwidth|0b00 |Indexed|
+|xdimsz|mode | zdimsz | submode2| invxyz |offset|submode|0b01 |DCT/FFT|
+| rsvd |rsvd |xdimsz | rsvd | invxyz |offset|submode|0b10 |Preduce|
+| | | | | | | |0b11 |rsvd |
-mode sets different behaviours (straight matrix multiply, FFT, DCT).
+`mode` sets different behaviours (straight matrix multiply, FFT, DCT).
* **mode=0b00** sets straight Matrix Mode
* **mode=0b00** with permute=0b110 or 0b111 sets Indexed Mode
* **mode=0b01** sets "FFT/DCT" mode and activates submodes
* **mode=0b10** sets "Parallel Reduction" Schedules.
+*Architectural Resource Allocation note: the four SVSHAPE SPRs are best
+allocated sequentially and contiguously in order that `sv.mtspr` may
+be used*
+
## Parallel Reduction Mode
Creates the Schedules for Parallel Tree Reduction.
offset will have the effect of offsetting the result by ```offset``` elements:
+```
for i in 0..VL-1:
GPR(RT + remap(i) + SVSHAPE.offset) = ....
+```
this appears redundant because the register RT could simply be changed by a compiler, until element width overrides are introduced. also
bear in mind that unlike a static compiler SVSHAPE.offset may
The format of the array is therefore as follows:
+```
array[xdimsz+1][ydimsz+1][zdimsz+1]
+```
However whilst illustrative of the dimensionality, that does not take the
"permute" setting into account. "permute" may be any one of six values
In its simplest form (without elwidth overrides or other modes):
```
-def index_remap(i):
- return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
+ def index_remap(i):
+ return GPR((SVSHAPE.SVGPR<<1)+i) + SVSHAPE.offset
-for i in 0..VL-1:
- element_result = ....
- GPR(RT + indexed_remap(i)) = element_result
+ for i in 0..VL-1:
+ element_result = ....
+ GPR(RT + indexed_remap(i)) = element_result
```
With element-width overrides included, and using the pseudocode
this becomes:
```
-def index_remap(i):
- svreg = SVSHAPE.SVGPR << 1
- srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
- offs = SVSHAPE.offset
- return get_polymorphed_reg(svreg, srcwid, i) + offs
+ def index_remap(i):
+ svreg = SVSHAPE.SVGPR << 1
+ srcwid = elwid_to_bitwidth(SVSHAPE.elwid)
+ offs = SVSHAPE.offset
+ return get_polymorphed_reg(svreg, srcwid, i) + offs
-for i in 0..VL-1:
- element_result = ....
- rt_idx = indexed_remap(i)
- set_polymorphed_reg(RT, destwid, rt_idx, element_result)
+ for i in 0..VL-1:
+ element_result = ....
+ rt_idx = indexed_remap(i)
+ set_polymorphed_reg(RT, destwid, rt_idx, element_result)
```
Matrix-style reordering still applies to the indices, except limited
to up to 2 Dimensions (X,Y). Ordering is therefore limited to (X,Y) or
-(Y,X). Only one dimension may optionally be skipped. Inversion of either
-X or Y or both is possible. Pseudocode for Indexed Mode (including elwidth
+(Y,X) for in-place Transposition.
+Only one dimension may optionally be skipped. Inversion of either
+X or Y or both is possible (2D mirroring). Pseudocode for Indexed Mode (including elwidth
overrides) may be written in terms of Matrix Mode, specifically
purposed to ensure that the 3rd dimension (Z) has no effect:
```
-def index_remap(ISHAPE, i):
- MSHAPE.skip = 0b0 || ISHAPE.sk1
- MSHAPE.invxyz = 0b0 || ISHAPE.invxy
- MSHAPE.xdimsz = ISHAPE.xdimsz
- MSHAPE.ydimsz = ISHAPE.ydimsz
- MSHAPE.zdimsz = 0 # disabled
- if ISHAPE.permute = 0b110 # 0,1
- MSHAPE.permute = 0b000 # 0,1,2
- if ISHAPE.permute = 0b111 # 1,0
- MSHAPE.permute = 0b010 # 1,0,2
- el_idx = remap_matrix(MSHAPE, i)
- svreg = ISHAPE.SVGPR << 1
- srcwid = elwid_to_bitwidth(ISHAPE.elwid)
- offs = ISHAPE.offset
- return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
+ def index_remap(ISHAPE, i):
+ MSHAPE.skip = 0b0 || ISHAPE.sk1
+ MSHAPE.invxyz = 0b0 || ISHAPE.invxy
+ MSHAPE.xdimsz = ISHAPE.xdimsz
+ MSHAPE.ydimsz = ISHAPE.ydimsz
+ MSHAPE.zdimsz = 0 # disabled
+ if ISHAPE.permute = 0b110 # 0,1
+ MSHAPE.permute = 0b000 # 0,1,2
+ if ISHAPE.permute = 0b111 # 1,0
+ MSHAPE.permute = 0b010 # 1,0,2
+ el_idx = remap_matrix(MSHAPE, i)
+ svreg = ISHAPE.SVGPR << 1
+ srcwid = elwid_to_bitwidth(ISHAPE.elwid)
+ offs = ISHAPE.offset
+ return get_polymorphed_reg(svreg, srcwid, el_idx) + offs
```
The most important observation above is that the Matrix-style
may have been costly to set up or costly to duplicate
(waste register file space).
+-------------
+
+\newpage{}
+
# svshape instruction <a name="svshape"> </a>
+SVM-Form
+
+ svshape SVxd,SVyd,SVzd,SVRM,vf
+
+| 0:5|6:10 |11:15 |16:20 | 21:24 | 25 | 26:31 | name |
+| -- | -- | --- | ----- | ------ | -- | ------| -------- |
+|PO | SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
+
+See [[sv/remap/appendix]] for `svshape` pseudocode
+
+Special Registers Altered:
+
+```
+ SVSTATE, SVSHAPE0-3
+```
+
`svshape` is a convenience instruction that reduces instruction
count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
(overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
including VL and MAXVL. Using `svshape` therefore does not also
require `setvl`.
-Form: SVM-Form SV "Matrix" Form (see [[isatables/fields.text]])
-
- svshape SVxd,SVyd,SVzd,SVRM,vf
-
-| 0.5|6.10 |11.15 |16..20 | 21..24 | 25 | 26..31| name |
-| -- | -- | --- | ----- | ------ | -- | ------| -------- |
-|OPCD| SVxd | SVyd | SVzd | SVRM | vf | XO | svshape |
-
Fields:
* **SVxd** - SV REMAP "xdim"
*Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
+There are 12 REMAP Modes (2 Modes are RESERVED for `svshape2`, 2 Modes
+are RESERVED)
+
| SVRM | Remap Mode description |
| -- | -- |
| 0b0000 | Matrix 1/2/3D |
| 0b1111 | FFT half-swap |
Examples showing how all of these Modes operate exists in the online
-[SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD)
-and the full pseudocode setting up all SPRs
-is in the [[openpower/isa/simplev]] page.
+[SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD). Explaining
+these Modes further in detail is beyond the scope of this document.
In Indexed Mode, there are only 5 bits available to specify the GPR
to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
instruction, `psvshape`, may extend the capability here.
+*Architectural Resource Allocation note: the SVRM field is carefully
+crafted to allocate two Modes, corresponding to bits 21-23 within the
+instruction being set to the value `0b100`, to `svshape2` (not
+`svshape`). These two Modes are
+considered "RESERVED" within the context of `svshape` but it is
+absolutely critical to allocate the exact same pattern in XO for
+both instructions in bits 26-31.*
+
+-------------
+
+\newpage{}
+
+
# svindex instruction <a name="svindex"> </a>
-`svindex` is a convenience instruction that reduces instruction
-count for Indexed REMAP Mode. It sets up
-(overwrites) all required SVSHAPE SPRs and can modify the REMAP
-SPR as well. The relevant SPRs *may* be directly programmed with
-`mtspr` however it is laborious to do so: svindex saves instructions
-covering much of Indexed REMAP capability.
+SVI-Form
+
+| 0:5|6:10 |11:15 |16:20 | 21:25 | 26:31 | Form |
+| -- | -- | --- | ---- | ----------- | ------| -------- |
+| PO | SVG | rmm | SVd | ew/yx/mm/sk | XO | SVI-Form |
-Form: SVI-Form SV "Indexed" Form (see [[isatables/fields.text]])
+* svindex SVG,rmm,SVd,ew,SVyx,mm,sk
- svindex SVG,rmm,SVd,ew,yx,mr,sk
+See [[sv/remap/appendix]] for `svindex` pseudocode
-| 0.5|6.10 |11.15 |16.20 | 21..25 | 26..31| name | Form |
-| -- | -- | --- | ---- | ----------- | ------| -------- | ---- |
-|OPCD| SVG | rmm | SVd | ew/yx/mm/sk | XO | svindex | SVI-Form |
+Special Registers Altered:
+
+```
+ SVSTATE, SVSHAPE0-3
+```
+
+`svindex` is a convenience instruction that reduces instruction count
+for Indexed REMAP Mode. It sets up (overwrites) all required SVSHAPE
+SPRs and **unlike** `svshape` can modify the REMAP area of the SVSTATE
+SPR as well, including setting persistence. The relevant SPRs *may*
+be directly programmed with `mtspr` however it is laborious to do so:
+svindex saves instructions covering much of Indexed REMAP capability.
Fields:
-* **SVd** - SV REMAP x/y dim
+* **SVd** - SV REMAP x/y dim
* **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
controlled by mm
* **ew** - sets element width override on the Indices
* **yx** - 2D reordering to be used if yx=1
* **mm** - mask mode. determines how `rmm` is interpreted.
* **sk** - Dimension skipping enabled
-* **XO** - standard 6-bit XO field
*Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
"off-by-one". In the assembler
When `mm=0`:
-* `rmm`, like REMAP.SVme, has bit 0
+* `rmm`, like REMAP.SVme, has bit 0
correspond to mi0, bit 1 to mi1, bit 2 to mi2,
bit 3 to mo0 and bit 4 to mi1
* all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
Rough algorithmic form:
+```
marray = [mi0, mi1, mi2, mo0, mo1]
idx = 0
for bit = 0 to 4:
setup(SVSHAPE[idx])
SVSTATE{marray[bit]} = idx
idx = (idx+1) modulo 4
+```
When `mm=1`:
Rough algorithmic form:
+```
marray = [mi0, mi1, mi2, mo0, mo1]
bit = rmm[0:2]
idx = rmm[3:4]
setup(SVSHAPE[idx])
SVSTATE{marray[bit]} = idx
SVSTATE.pst = 1
+```
In essence, `mm=0` is intended for use to set as much of the
REMAP State SPRs as practical with a single instruction,
Beyond these mappings it becomes necessary to write directly to
the SVSTATE SPRs manually.
-# svshape2 (offset) <a name="svshape2"> </a>
+-------------
+
+\newpage{}
+
+
+# svshape2 (offset-priority) <a name="svshape2"> </a>
+
+SVM2-Form
+
+| 0:5|6:9 |10|11:15 |16:20 | 21:24 | 25 | 26:31 | Form |
+| -- |----|--| --- | ----- | ------ | -- | ------| -------- |
+| PO |offs|yx| rmm | SVd | 100/mm | sk | XO | SVM2-Form |
+
+* svshape2 offs,yx,rmm,SVd,sk,mm
+
+See [[sv/remap/appendix]] for `svshape2` pseudocode
+
+Special Registers Altered:
+
+```
+ SVSTATE, SVSHAPE0-3
+```
`svshape2` is an additional convenience instruction that prioritises
setting `SVSHAPE.offset`. Its primary purpose is for use when
-element-width overrides are used. It has identical capabilities to `svindex` and
+element-width overrides are used. It has identical capabilities to `svindex`
in terms of both options (skip, etc.) and ability to activate REMAP
-(rmm, mask mode) but unlike `svindex` it does not set GPR REMAP,
+(rmm, mask mode) but unlike `svindex` it does not set GPR REMAP:
only a 1D or 2D `svshape`, and
-unlike `svshape` it can set an arbirrary `SVSHAPE.offset` immediate.
+unlike `svshape` it can set an arbitrary `SVSHAPE.offset` immediate.
One of the limitations of Simple-V is that Vector elements start on the boundary
of the Scalar regfile, which is fine when element-width overrides are not
needed. If the starting point of a Vector with smaller elwidths must begin
in the middle of a register, normally there would be no way to do so except
-through LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`is
-makes it easier.
-
- svshape2 offs,yx,rmm,SVd,sk,mm
+through costly LD/ST. `SVSHAPE.offset` caters for this scenario and `svshape2`
+makes it easier to access.
-| 0.5|6..9|10|11.15 |16..20 | 21..25 | 25 | 26..31| name |
-| -- |----|--| --- | ----- | ------ | -- | ------| -------- |
-|OPCD|offs|yx| rmm | SVd | 100/mm | sk | XO | svshape |
+**Operand Fields**:
* **offs** (4 bits) - unsigned offset
* **yx** (1 bit) - swap XY to YX
* **sk** (1 bit) skips 1st dimension if set
Dimensions are calculated exactly as `svindex`. `rmm` and
-`mm` are as per `svindex`.
+`mm` are as per `svindex`.
*Programmer's Note: offsets for `svshape2` may be specified in the range
0-15. Given that the principle of Simple-V is to fit on top of
reading the contents of any SPRs. If however there are
instructions that have directly written to the SVSTATE or SVSHAPE
SPRs and those instructions are still in-flight then this position
-is clearly **invalid**.*
+is clearly **invalid**. This is why Programmers are strongly
+discouraged from directly writing to these SPRs.*
+
+*Architectural Resource Allocation note: this instruction shares
+the space of `svshape`. Therefore it is critical that the two
+instructions, `svshape` and `svshape2` have the exact same XO
+in bits 26 thru 31. It is also critical that for `svshape2`,
+bit 21 of XO is a 1, bit 22 of XO is a 0, and bit 23 of XO is a 0.*
+
+[[!tag standards]]
+
+-------------
-# TODO
+\newpage{}
-* investigate https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6879380/#!po=19.6429
-in https://bugs.libre-soc.org/show_bug.cgi?id=653
-* UTF-8 <https://bugs.libre-soc.org/show_bug.cgi?id=794>
-* Triangular REMAP
-* Cross-Product REMAP (actually, skew Matrix: https://en.m.wikipedia.org/wiki/Skew-symmetric_matrix)
-* Convolution REMAP
projects / libreriscv.git / blobdiff