(no commit message)

diff --git a/openpower/sv/remap.mdwn b/openpower/sv/remap.mdwn
index fbf26b2485b4f0f3378d722a6facd20891f61a98..49a1d0863df33c1cfbf37e66155491b7922c1313 100644 (file)
--- a/openpower/sv/remap.mdwn
+++ b/openpower/sv/remap.mdwn
@@ -214,6 +214,28 @@ 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).
 
+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
+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`.
+
+Indexed REMAP on the other hand **does not prevent conflicts** (overlapping
+destinations), which on a superficial analysis may be perceived to be a
+problem, until it is recalled that, firstly, Simple-V is designed specifically
+to require Program Order to be respected, and that Matrix, DCT and FFT
+all *already* critically depend on overlapping Reads/Writes: Matrix
+uses overlapping registers as accumulators.  Thus the Register Hazard
+Management needed by Indexed REMAP *has* to be in place anyway.
+
+*Programmer's note: some algorithms may require truncating permutations
+to VL, not MAXVL. This may be achieved programmatically by performing
+a `sv.cmp *RA,RB` where RA is the same GPRs used in the Indexed REMAP,
+and RB contains the value of VL returned from `setvl`. The resultant
+CR Fields may then be used as Predicate Masks to exclude those operations
+with an Index exceeding VL*
+
 # REMAP area of SVSTATE
 
 The following bits of the SVSTATE SPR are used for REMAP: