From f6b126d4460c45712fe70631176dc6efa8812d37 Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 21 Apr 2022 13:21:53 +0100 Subject: [PATCH] --- openpower/sv/biginteger/analysis.mdwn | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/openpower/sv/biginteger/analysis.mdwn b/openpower/sv/biginteger/analysis.mdwn index 518912630..8c30e2e9c 100644 --- a/openpower/sv/biginteger/analysis.mdwn +++ b/openpower/sv/biginteger/analysis.mdwn @@ -37,13 +37,18 @@ This pattern - sequential execution of individual instructions with incrementing register numbers - is precisely the very definition of how SVP64 works! Thus, due to sequential execution of `adde` both consuming and producing -a CA Flag, `sv.adde` is in effect an alias for Vectorised add. As such, +a CA Flag, with no additions to SVP64 or to the v3.0 Power ISA, +`sv.adde` is in effect an alias for Big-Integer Vectorised add. As such, implementors are entirely at liberty to recognise Horizontal-First Vector adds and send the vector of registers to a much larger and wider back-end -ALU, and/or short-cut the intermediate storage of XER.CA on an element -level and implement a Vector-aware carry propagation algorithm -in back-end hardware that need only read the first incoming XER.CA and -only store the last XER.CA. The size of the underlying back-end SIMD ALU +ALU, and short-cut the intermediate storage of XER.CA on an element +level in back-end hardware that need only: + +* read the first incoming XER.CA +* implement a Vector-aware carry propagation algorithm +* store the very last XER.CA in the batch + +The size and implementation of the underlying back-end SIMD ALU is entirely at the discretion of the implementer. If there is pressure on the register file (or -- 2.30.2