move regfile section

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index aaa6eb73a8ed7f39a2a52ca756e70c91758963f0..73083fcec71461e9ef36cd391a04a68be0a3b872 100644 (file)
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -106,45 +106,6 @@ Any operation that inherently makes no sense if repeated is termed
 which have no registers. `mtmsr` is also classed as UnVectoriseable
 because there is only one `MSR`.
 
-## Scalar Identity Behaviour
-
-SVP64 is designed so that when the prefix is all zeros, and
- VL=1, no effect or
-influence occurs (no augmentation) such that all standard Power ISA
-v3.0/v3 1 instructions covered by the prefix are "unaltered". This
-is termed `scalar identity behaviour` (based on the mathematical
-definition for "identity", as in, "identity matrix" or better "identity
-transformation").
-
-Note that this is completely different from when VL=0.  VL=0 turns all
-operations under its influence into `nops` (regardless of the prefix)
- whereas when VL=1 and the SV prefix is all zeros, the operation simply
- acts as if SV had not been applied at all to the instruction  (an
- "identity transformation").
-
-## Register Naming and size
-
-As expanded on below SV Registers are simply the INT, FP and CR
-register files extended linearly to larger sizes; SV Vectorisation
-iterates sequentially through these registers (LSB0 sequential ordering
-from 0 to VL-1).
-
-Where the integer regfile in standard scalar Power ISA v3.0B/v3.1B is
-r0 to r31, SV extends this as r0 to r127.  Likewise FP registers are
-extended to 128 (fp0 to fp127), and CR Fields are extended to 128 entries,
-CR0 thru CR127.
-
-The names of the registers therefore reflects a simple linear extension
-of the Power ISA v3.0B / v3.1B register naming, and in hardware this
-would be reflected by a linear increase in the size of the underlying
-SRAM used for the regfiles.
-
-Note: when an EXTRA field (defined below) is zero, SV is deliberately
-designed so that the register fields are identical to as if SV was not in
-effect i.e. under these circumstances (EXTRA=0) the register field names
-RA, RB etc. are interpreted and treated as v3.0B / v3.1B scalar registers.
-This is part of `scalar identity behaviour` described above.
-
 ## Register files, elements, and Element-width Overrides
 
 In the Upper Compliancy Levels the size of the GPR and FPR Register
@@ -231,6 +192,45 @@ write-enable line.  It is up to the Hardware Architect to then amortise
 as simultaneous non-overlapping Register File writes, to achieve High
 Performance designs.
 
+## Scalar Identity Behaviour
+
+SVP64 is designed so that when the prefix is all zeros, and
+ VL=1, no effect or
+influence occurs (no augmentation) such that all standard Power ISA
+v3.0/v3 1 instructions covered by the prefix are "unaltered". This
+is termed `scalar identity behaviour` (based on the mathematical
+definition for "identity", as in, "identity matrix" or better "identity
+transformation").
+
+Note that this is completely different from when VL=0.  VL=0 turns all
+operations under its influence into `nops` (regardless of the prefix)
+ whereas when VL=1 and the SV prefix is all zeros, the operation simply
+ acts as if SV had not been applied at all to the instruction  (an
+ "identity transformation").
+
+## Register Naming and size
+
+As indicated above SV Registers are simply the INT, FP and CR
+register files extended linearly to larger sizes; SV Vectorisation
+iterates sequentially through these registers (LSB0 sequential ordering
+from 0 to VL-1).
+
+Where the integer regfile in standard scalar Power ISA v3.0B/v3.1B is
+r0 to r31, SV extends this as r0 to r127.  Likewise FP registers are
+extended to 128 (fp0 to fp127), and CR Fields are extended to 128 entries,
+CR0 thru CR127.
+
+The names of the registers therefore reflects a simple linear extension
+of the Power ISA v3.0B / v3.1B register naming, and in hardware this
+would be reflected by a linear increase in the size of the underlying
+SRAM used for the regfiles.
+
+Note: when an EXTRA field (defined below) is zero, SV is deliberately
+designed so that the register fields are identical to as if SV was not in
+effect i.e. under these circumstances (EXTRA=0) the register field names
+RA, RB etc. are interpreted and treated as v3.0B / v3.1B scalar registers.
+This is part of `scalar identity behaviour` described above.
+
 ## Future expansion.
 
 With the way that EXTRA fields are defined and applied to register fields,