From: lkcl Date: Thu, 21 Apr 2022 12:21:53 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2648 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f6b126d4460c45712fe70631176dc6efa8812d37;p=libreriscv.git --- 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