(no commit message)

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index fcdc45a1ade6e580809bc0c506860dca3e4b01b2..0e4eee6c4a7faa9c8b9c320dab1cf6e9f1428624 100644 (file)
--- a/openpower/sv/svp64/appendix.mdwn
+++ b/openpower/sv/svp64/appendix.mdwn
@@ -656,11 +656,13 @@ Numbering relationships for CR fields are already complex due to being
 in BE format (*the relationship is not clearly explained in the v3.0B
 or v3.1 specification*).  However with some care and consideration
 the exact same mapping used for INT and FP regfiles may be applied,
-just to the upper bits, as explained below.  The notation
+just to the upper bits, as explained below.  Firstly and most
+importantly a new notation
 `CR{field number}` is used to indicate access to a particular
 Condition Register Field (as opposed to the notation `CR[bit]`
 which accesses one bit of the 32 bit Power ISA v3.0B
-Condition Register)
+Condition Register).
+
 
 `CR{n}` refers to `CR0` when `n=0` and consequently, for CR0-7, is defined, in v3.0B pseudocode, as:
 
@@ -670,6 +672,12 @@ 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
+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..`
+in Vector Loops.
+
 In OpenPOWER v3.0/1, BF/BT/BA/BB are all 5 bits.  The top 3 bits (0:2)
 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