From: lkcl Date: Tue, 16 Aug 2022 20:18:52 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~849 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=5a4a42ff5d407158a090369040b9e73fede68cf0;p=libreriscv.git --- diff --git a/openpower/sv/remap.mdwn b/openpower/sv/remap.mdwn index fbf26b248..49a1d0863 100644 --- 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: