From: lkcl <lkcl@web>
Date: Wed, 12 Apr 2023 21:23:30 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls010_v1~41
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=70d03fefcbfc2e86c0aa5be1032ab4e8c4a1d47e;p=libreriscv.git

---

diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn
index c1fe4886d..e87ed4e1a 100644
--- a/openpower/sv/cr_ops.mdwn
+++ b/openpower/sv/cr_ops.mdwn
@@ -194,12 +194,16 @@ result to zero, and also all subsequent CR Field elements thereafter:
 
 `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
+calculation could be carried out (`parityw`)
+after transferring a vector of CR Fields
 to a GPR using crweird operations.
 
 Implementations are free and clear to optimise these reductions in any way
 they see fit, as long as the end-result is compatible with Strict Program
 Order being observed, and Interrupt latency is not adversely impacted.
+Good examples include `sv.cror/mr` which is a cumulative ORing of
+a Vector of CR Field bits, and consequently an easy target for
+parallelising.
 
 ## Unusual and quirky CR operations
 
@@ -212,7 +216,7 @@ Order being observed, and Interrupt latency is not adversely impacted.
     cmpeqb BF,RA,RB
 ```
 
-With `ELWIDTH` applying to the source GPR operands this is perfectly fine.
+With `ELWIDTH` applying to the source GPR operands this is perfectly fine. 
 
 **crweird operations**