From: lkcl 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**