(no commit message)

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index d04d66de7bbe57c04efdf0d31ba88f613fe1b8f7..18be50fba8abe91a922d1fb720d2ac8f0dec9a76 100644 (file)
--- 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:
-<https://bugs.libre-soc.org/show_bug.cgi?id=697#c11>
+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.*