move regfile section

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index ba99bd601e0fbe0ea6dce461914125e1042c5250..34a382f4aa5e858b3c4eaf5d351a039ef4982f1f 100644 (file)
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -67,6 +67,61 @@ rules are followed, allowing for full soft-emulation including future
 revisions.  Compliancy Subsets exist to ensure minimum levels of binary
 interoperability expectations within certain environments.
 
+## SVP64 encoding features
+
+A number of features need to be compacted into a very small space of
+only 24 bits:
+
+* Independent per-register Scalar/Vector tagging and range extension on
+  every register
+* Element width overrides on both source and destination
+* Predication on both source and destination
+* Two different sources of predication: INT and CR Fields
+* SV Modes including saturation (for Audio, Video and DSP), mapreduce,
+  fail-first and predicate-result mode.
+
+Different classes of operations require different formats. The earlier
+sections cover the c9mmon formats and the four separate modes follow:
+CR operations (crops), Arithmetic/Logical (termed "normal"), Load/Store
+and Branch-Conditional.
+
+## Definition of Reserved in this spec.
+
+For the new fields added in SVP64, instructions that have any of their
+fields set to a reserved value must cause an illegal instruction trap,
+to allow emulation of future instruction sets, or for subsets of SVP64 to
+be implemented in hardware and the rest emulated.  This includes SVP64
+SPRs: reading or writing values which are not supported in hardware
+must also raise illegal instruction traps in order to allow emulation.
+Unless otherwise stated, reserved values are always all zeros.
+
+This is unlike OpenPower ISA v3.1, which in many instances does not
+require a trap if reserved fields are nonzero.  Where the standard Power
+ISA definition is intended the red keyword `RESERVED` is used.
+
+##  Definition of "UnVectoriseable"
+
+Any operation that inherently makes no sense if repeated is termed
+"UnVectoriseable" or "UnVectorised".  Examples include `sc` or `sync`
+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 files, elements, and Element-width Overrides
 
 In the Upper Compliancy Levels the size of the GPR and FPR Register
@@ -153,61 +208,6 @@ 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.
 
-## SVP64 encoding features
-
-A number of features need to be compacted into a very small space of
-only 24 bits:
-
-* Independent per-register Scalar/Vector tagging and range extension on
-  every register
-* Element width overrides on both source and destination
-* Predication on both source and destination
-* Two different sources of predication: INT and CR Fields
-* SV Modes including saturation (for Audio, Video and DSP), mapreduce,
-  fail-first and predicate-result mode.
-
-Different classes of operations require different formats. The earlier
-sections cover the c9mmon formats and the four separate modes follow:
-CR operations (crops), Arithmetic/Logical (termed "normal"), Load/Store
-and Branch-Conditional.
-
-## Definition of Reserved in this spec.
-
-For the new fields added in SVP64, instructions that have any of their
-fields set to a reserved value must cause an illegal instruction trap,
-to allow emulation of future instruction sets, or for subsets of SVP64 to
-be implemented in hardware and the rest emulated.  This includes SVP64
-SPRs: reading or writing values which are not supported in hardware
-must also raise illegal instruction traps in order to allow emulation.
-Unless otherwise stated, reserved values are always all zeros.
-
-This is unlike OpenPower ISA v3.1, which in many instances does not
-require a trap if reserved fields are nonzero.  Where the standard Power
-ISA definition is intended the red keyword `RESERVED` is used.
-
-##  Definition of "UnVectoriseable"
-
-Any operation that inherently makes no sense if repeated is termed
-"UnVectoriseable" or "UnVectorised".  Examples include `sc` or `sync`
-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 previously mentioned SV Registers are simply the INT, FP and CR