From: lkcl <lkcl@web>
Date: Sun, 21 Aug 2022 17:28:55 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~800
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=b2d30185afd291e42dc827b5db1867a116692d0b;p=libreriscv.git

---

diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn
index 11ed17be9..f631b58e3 100644
--- a/openpower/sv/cr_ops.mdwn
+++ b/openpower/sv/cr_ops.mdwn
@@ -17,7 +17,7 @@ Condition Register Fields are only 4 bits wide: this presents some
 interesting conceptual challenges for SVP64, which was designed
 primarily for vectors of arithmetic and logical operations. However
 if predicates may be bits of CR Fields it makes sense to extend
-SVP64 to cover CR Operations.
+Simple-V to cover CR Operations.
 
 Element width however is clearly meaningless for a 4-bit
 collation of Conditions, EQ LT GE SO. Likewise, arithmetic saturation
@@ -34,7 +34,7 @@ Instructions that involve Rc=1 are definitively arithmetic in nature,
 where the corresponding Condition Register Field can be considered to
 be a "co-result". Such CR Field "co-result" arithmeric operations
 are firmly out of scope for
-this section.
+this section, being covered fully by [[sv/normal]].
 
 * Examples of v3.0B instructions to which this section does
   apply is
@@ -68,6 +68,12 @@ allows the decision to be made to store or not store the main
 result, and for CR Ops the CR Field result *is*
 the main result.
 
+*Programmer's note: 
+`sv.crxor` with reduction would be particularly useful for parity calculation
+for example, although there are many ways in which the same calculation
+could be carried out after transferring a vector of CR Fields to a GPR
+using crweird operations.*
+
 # Format
 
 SVP64 RM `MODE` (includes `ELWIDTH_SRC` bits) for CR-based operations: