From: lkcl <lkcl@web>
Date: Thu, 22 Sep 2022 16:47:16 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~328
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=9252fc658cf0c2d2aee43c5944af0d4ef40a8197;p=libreriscv.git

---

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index 0e4eee6c4..fc27c620c 100644
--- a/openpower/sv/svp64/appendix.mdwn
+++ b/openpower/sv/svp64/appendix.mdwn
@@ -672,7 +672,7 @@ For SVP64 the relationship for the sequential
 numbering of elements is to the CR **fields** within
 the CR Register, not to individual bits within the CR register.
 
-This notation is designed to give *linear sequential
+The `CR{n}` notation is designed to give *linear sequential
 numbering* in the Vector domain on a straight sequential Vector Loop.
 Without it, there is the risk of massive confusion as CR Fields
 could be accessed in order `CR7 CR6 ... CR0 CR15 CR14 .. CR8 CR23..`
@@ -683,14 +683,15 @@ select one of the 8 CRs; the bottom 2 bits (3:4) select one of 4 bits
 *in* that CR (EQ/LT/GT/SO).  The numbering was determined (after 4 months of
 analysis and research) to be as follows:
 
-    CR_index = 7-(BA>>2)      # top 3 bits but BE
-    bit_index = 3-(BA & 0b11) # low 2 bits but BE
+    CR_index = 7-(BA>>2)      # top 3 bits but de-MSB0'd
+    bit_index = 3-(BA & 0b11) # low 2 bits but de-MSB0'd
     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 (bits 3-4):
+When it comes to applying SV, it is the *CR Field* number `CR\_reg`
+to which SV EXTRA2/3
+applies, **not** the `CR\_bit` portion (bits 3-4):
 
     if extra3_mode:
         spec = EXTRA3