From b22a0667622cbf111eb34a1b17ac8023db3f08aa Mon Sep 17 00:00:00 2001
From: lkcl <lkcl@web>
Date: Sun, 20 Dec 2020 14:03:07 +0000
Subject: [PATCH]

---
 openpower/sv/svp_rewrite/svp64.mdwn | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/openpower/sv/svp_rewrite/svp64.mdwn b/openpower/sv/svp_rewrite/svp64.mdwn
index 8dc29a055..c7ec98395 100644
--- a/openpower/sv/svp_rewrite/svp64.mdwn
+++ b/openpower/sv/svp_rewrite/svp64.mdwn
@@ -492,7 +492,27 @@ i.e. under these circumstances (EXTRA=0) the register field names RA,
 RB etc. are interpreted as v3.0B / v3.1B scalar registers.  This is termed
 `scalar identity behaviour`
 
-# Operation
+# CR Operations
+
+## EXTRA mapping algorithm
+
+Numbering relationships for CR fields are already complex due to bring in BE format.  In OpenPOWER v3.0/1, BFA is 5 bits in order to select one of 4 bits from one of the 8 CRs.  The numbering was determined - after 4 months - to be as follows:
+
+    CR_index = 7-BFA>>2        # top 3 bits but BE
+    bit_index = 3-(BFA & 0b11) # low 2 bits but BE
+    CR_reg = CR[CR_index]      # get the CR
+    # finally get the bit from the CR
+    CR_bit = (CR_reg & (1<<bit_index)) != 0
+
+When it comes to applying SV, it is the CR_reg number to which SV EXTRA2/3 applies, **not** the CR_bit portion.
+
+    spec = EXTRA3
+    if spec[2]: # vector
+       return ((BFA >> 2)<<4) | # hi 3 bits shifted up
+              (spec[0:1]<<2) |  # to make room for these
+              (BFA & 0b11)      # CR_bit on the end
+    else:         # scalar
+       return BFA + spec[0:1] << 7
 
 ## CR fields as inputs/outputs of vector operations
 
-- 
2.30.2