From: lkcl Date: Mon, 11 Apr 2022 07:56:11 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2794 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=c691175f4451c9ece87831d73cde8be72b5058d3;p=libreriscv.git --- diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn index d04d66de7..18be50fba 100644 --- a/openpower/sv/svp64/appendix.mdwn +++ b/openpower/sv/svp64/appendix.mdwn @@ -855,9 +855,15 @@ def reduce(vl, vec, pred): pred[i] |= other_pred; ``` -we'd want to use something based on the above pseudo-code -rather than the below pseudo-code -- reasoning here: - +The principle in SVP64 being violated is that SVP64 is a fully-independent +Abstraction of hardware-looping in between issue and execute phases +that has no relation to the operation it issues. The above pseudocode +conditionally changes not only the type of element operation issued +(a MV in some cases) but also the number of arguments (2 for a MV). +At the very least, for Vertical-First Mode this will result in unanticipated and unexpected behaviour (maximise "surprises" for programmers) in +the middle of loops, that will be far too hard to explain. + +An alternative algorithm is therefore required that does not perform MVs. ``` def reduce( vl, vec, pred, pred,): @@ -880,3 +886,14 @@ def reduce( vl, vec, pred, pred,): step *= 2 ``` + +*Implementor's Note: many SIMD-based Parallel Reduction Algorithms are +implemented in hardware with MVs that ensure lane-crossing is minimised. +In SIMD ISAs the internal SIMD Architectural design is exposed and imposed on the programmer. Cray-style Vector ISAs on the other hand provide convenient, +compact and efficient encodings of abstract concepts. +It is the Implementor's responsibility to produce a design +that complies with the above algorithm, +utilising internal Micro-coding and other techniques to transparently +insert MV operations +if necessary or desired, to give the level of efficiency or performance +required.*