(no commit message)

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index c46b24bcd80d2ecae29e9ca2498e3c999f2c34a0..c1f83f8344b686e8a03957fa68d933c8ad3174f8 100644 (file)
--- a/openpower/sv/svp64/appendix.mdwn
+++ b/openpower/sv/svp64/appendix.mdwn
@@ -314,7 +314,7 @@ Thus the compiler when referring to CR0 still generates code that it thinks is s
 
 In concrete terms: when the Vector looping proceeds to increment Integer or FP register numbers linearly, `fp1 fp2 fp3...` when `Rc=1` the Vector of CRs should start at `CR1` just as they do in scalar execution but *not overwrite CR2*.  Instead proceed to write to at least 8 or 16 CRs before doing so.
 
-Two ways in which this may occur: either for numbering to be linear (`CR8, CR9`) or to be expressed as sub-numbers similar to FP: `CR1.0 CR1.1 ... CR1.15 CR2.0`. Fractional numbering is more natural and intuitive.  Here is a table showing progression from 0 to VL-1 when VL=18, should an Integer Vector operation writes first to `CR0`.  It is the 16th element before `CR1` is overwritten: 
+Two ways in which this may occur: either for numbering to be linear (`CR0..CR127`) but to jump in increments of 8, or to be expressed as sub-numbers similar to FP: `CR1.0 CR1.1 ... CR1.15 CR2.0`. Fractional numbering is more natural and intuitive.  Here is a table showing progression from 0 to VL-1 when VL=18, should an Integer Vector operation writes first to `CR0`.  It is the 16th element before `CR1` is overwritten: 
 
     CRn.0     CR0 0  CR1 16 CR2    CR3    CR4   CR5   CR6   CR7
     CRn.1         1      17
@@ -344,7 +344,7 @@ analysis and research) to be as follows:
     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 0:1):
+applies, **not** the CR\_bit portion (bits 0:1).
 
     if extra3_mode:
         spec = EXTRA3