From 70d03fefcbfc2e86c0aa5be1032ab4e8c4a1d47e Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 12 Apr 2023 22:23:30 +0100 Subject: [PATCH] --- openpower/sv/cr_ops.mdwn | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) 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** -- 2.30.2