(no commit message)

[libreriscv.git] / openpower / sv / cr_ops.mdwn

diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn
index c1fe4886dca5ddc1bfefaa06268ee27462c4178a..7ee59bc94562b3e5878d5df5220ebb3baa699fe7 100644 (file)
--- a/openpower/sv/cr_ops.mdwn
+++ b/openpower/sv/cr_ops.mdwn
@@ -51,6 +51,8 @@ by [[sv/normal]].
 * Examples to which this section does **not** apply include
   `fadds.` and `subf.` which both produce arithmetic results
   (and a CR Field co-result).
+* `mtcr` is considered [[openpower/sv/normal]] because it refers
+  to the entire 32-bit Condition Register rather than to CR Fields.
 
 The CR Mode Format still applies to `sv.cmpi` because despite
 taking a GPR as input, the output from the Base Scalar v3.0B `cmpi`
@@ -194,12 +196,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 +218,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**