(no commit message)

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 4874e4f518e735835cf7e62f49e2faff000c3fa0..54f25aabf83653f92db13424428a2184587b5826 100644 (file)
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -139,6 +139,25 @@ adding "UnVectorised" to this phase is not unreasonable.*
 
 ## Register files, elements, and Element-width Overrides
 
+The relationship between register files, elements, and element-width
+overrides is expressed as follows:
+
+* register files are considered to be *byte-level* contiguous SRAMs,
+  accessed exclusively in Little-Endian  Byte-Order at all times
+* elements are sequential contiguous unbounded arrays starting at the "address"
+  of any given 64-bit GPR or FPR, numbered from 0 as the first,
+  "spilling" into numerically-sequentially-increasing GPRs
+* element-width overrides set the width of the *elements* in the
+  sequentially-numbered contiguous array.
+
+The relationship is best defined in Canonical form, below, in ANSI c
+as a union data structure.  A key difference is that VSR elements are bounded
+fixed at 128-bit, where SVP64 elements are conceptually unbounded and
+only limited by the Maximum Vector Length.
+
+*Future specification note: SVP64 may be defined on top of VSRs in future.
+At which point VSX also gains conceptually unbounded VSR register elements*
+
 In the Upper Compliancy Levels of SVP64 the size of the GPR and FPR
 Register files are expanded from 32 to 128 entries, and the number of
 CR Fields expanded from CR0-CR7 to CR0-CR127. (Note: A future version
@@ -150,6 +169,16 @@ on the Load and Store memory-register operation byte-order, and having
 nothing to do with the ordering of the contents of register files or
 register-register operations.
 
+The only major impact on Arithmetic and Logical operations is that all
+Scalar operations are defined, where practical and workable, to have
+three new widths: elwidth=32, elwidth=16, elwidth=8.  The default of
+elwidth=64 is the pre-existing (Scalar) behaviour which remains 100%
+unchanged. Thus, `addi` is now joined by a 32-bit, 16-bit, and 8-bit
+variant of `addi`, but the sole exclusive difference is the width.
+*In no way* is the actual `addi` instruction fundamentally altered.
+FP Operations elwidth overrides are also defined, as explained in
+the [[svp64/appendix]].
+
 To be absolutely clear:
 
 ```