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

---

diff --git a/openpower/sv/biginteger/analysis.mdwn b/openpower/sv/biginteger/analysis.mdwn
index c98cdb8a3..5ba008fca 100644
--- a/openpower/sv/biginteger/analysis.mdwn
+++ b/openpower/sv/biginteger/analysis.mdwn
@@ -30,13 +30,16 @@ their element-level operations.
                    |
     R2,CA = A2+B2+CA  adde r2,a2,b2
 
+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,
 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 take the first incoming XER.CA and
+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
 is entirely at the discretion of the implementer.