(no commit message)

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index d171d4e14d376f84828a71e705cfc8b414089566..22ad094bb9ffbd84bfab5041b5283927bfe92dd8 100644 (file)
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -89,6 +89,54 @@ revisions.  Compliancy Subsets exist to ensure minimum levels of binary
 interoperability expectations within certain environments.  Details in
 the [[svp64/appendix]].
 
+## 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 common 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`.
+
+UnVectorised instructions are required to be detected as such if
+Prefixed (either SVP64 or SVP64Single) and an Illegal Instruction
+Trap raised.
+
+*Architectural Note: Given that a "pre-classification" Decode Phase is
+required (identifying whether the Suffix - Defined Word - is
+Arithmetic/Logical, CR-op, Load/Store or Branch-Conditional),
+adding "UnVectorised" to this phase is not unreasonable.*
+
 ## Strict Program Order
 
 Strict Program Order is defined as giving the appearance, as far
@@ -148,54 +196,6 @@ for example), which
 will force implementations to perform divide and modulo
 calculations.
 
-## 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 common 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`.
-
-UnVectorised instructions are required to be detected as such if
-Prefixed (either SVP64 or SVP64Single) and an Illegal Instruction
-Trap raised.
-
-*Architectural Note: Given that a "pre-classification" Decode Phase is
-required (identifying whether the Suffix - Defined Word - is
-Arithmetic/Logical, CR-op, Load/Store or Branch-Conditional),
-adding "UnVectorised" to this phase is not unreasonable.*
-
 ## Register files, elements, and Element-width Overrides
 
 The relationship between register files, elements, and element-width