From: lkcl <lkcl@web>
Date: Thu, 21 Apr 2022 08:47:06 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~2658
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=7917f99f5fe01d01ba824b0094fc60049adb8f34;p=libreriscv.git

---

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