From 4bf10e5b07c4d8edb7d29822ef64e6bccb50c1ae Mon Sep 17 00:00:00 2001 From: lkcl Date: Sun, 10 Apr 2022 16:57:02 +0100 Subject: [PATCH] --- openpower/sv/svp64/appendix.mdwn | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn index 67ecf048d..8b7ca773a 100644 --- a/openpower/sv/svp64/appendix.mdwn +++ b/openpower/sv/svp64/appendix.mdwn @@ -323,7 +323,7 @@ one register must be assigned, by convention by the programmer to be the are neither `UNDEFINED` nor prohibited, despite them not making much sense at first glance. Scalar reduce is strictly defined behaviour, and the cost in -hardware terms of prohibition of seemingly non-sensical operations is too great. +hardware terms of prohibition of seemingly non-sensical operations is too great. Therefore it is permitted and required to be executed successfully. Implementors **MAY** choose to optimise such instructions in instances where their use results in "extraneous execution", i.e. where it is clear @@ -332,7 +332,9 @@ a scalar destination **without** cumulative, iterative, or reductive behaviour (no "accumulator"), may discard all but the last element operation. Identification of such is trivial to do for `setb` and `cmp`: the source register type is -a completely different register file from the destination* +a completely different register file from the destination. +Likewise Scalar reduction when the destination is a Vector +is as if the Reduction Mode was not requested.* Typical applications include simple operations such as `ADD r3, r10.v, r3` where, clearly, r3 is being used to accumulate the addition of all -- 2.30.2