From: lkcl Date: Thu, 9 Jun 2022 09:55:57 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~1902 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=9498af2685c4438586919f781ea594586c2d2b98;p=libreriscv.git --- diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index a9f4c6f75..36b56042d 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -360,3 +360,38 @@ reduced to Read-After-Write (RAW) and that the WAR Hazard is removed. This is sort-of a quirk and sort-of not, because the option to support XER.SO is already optional from the SFFS Compliancy Level. + +# Indexed REMAP and CR Field Predication Hazards + +Normal Vector ISAs and those Packed SIMD ISAs inspired by them have +Vector "Permute" or "Shuffle" instructions. These provide a Vector of +indices whereby another Vector is reordered (permuted, shuffled) according +to the indices. Register Hazard Managent here is trivial because there +are three registers: indices source vector, elements source vector to +be shuffled, result vector. + +For SVP64 which is based on top of a Scalar Register File paradigm, +combined with the hard requirement to respect full Register Hazard +Management as if element instructions were actual Scalar instructions, +the addition of a Vector permute instruction under these strict +conditions would result in a catastrophic +reduction in performance. + +A little leniency and rule-bending is therefore required. + +Rather than add explicit Vector permute instructions, the "Indexing" +has been separated out into a REMAP Schedule. When an Indexed +REMAP is requested, it is assumed (required, of software) that +subsequent instructions intending to use those indices *will not* +attempt to modify the indices. It is *Software* that must consider them +to be read-only. + +This simple relaxation of the rules releases Hardware from having the +horrendous job of dynamically detecting Write-after-Read Hazards on a +huge range of registers. + +A similar Hazard problem exists for CR Field Predicates, in Vertical-First +Mode. Instructions could modify CR Fields currently being used as Predicate +Masks: detecting this is so horrendous for hardware resource utilisation +and hardware complexity that, again, the decision is made to relax these +constraints and for Software to take that into account.