(no commit message)

diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn
index c1fe4886dca5ddc1bfefaa06268ee27462c4178a..e87ed4e1af560a30b3b9c76d328c21f59df46c86 100644 (file)
--- 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**