From 7917f99f5fe01d01ba824b0094fc60049adb8f34 Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 21 Apr 2022 09:47:06 +0100 Subject: [PATCH] --- openpower/sv/biginteger/analysis.mdwn | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/openpower/sv/biginteger/analysis.mdwn b/openpower/sv/biginteger/analysis.mdwn index ce4898372..371e81926 100644 --- a/openpower/sv/biginteger/analysis.mdwn +++ b/openpower/sv/biginteger/analysis.mdwn @@ -19,11 +19,25 @@ big-integer add due to the rules set in SVP64 that all Vector Operations are directly equivalent to the strict Program Order Execution of their element-level operations. + R0,CA = A0+B0+CA + | + +----------+ + | + R1,CA = A1+B1+CA + | + +----------+ + | + R2,CA = A2+B2+CA + 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, 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. +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 take the first incoming XER.CA and +only store the last XER.CA. The size of the underlying back-end SIMD ALU +is entirely at the discretion of the implementer. # Multiply -- 2.30.2