(no commit message)

diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn
index a2fa075b16ea1200991f0d296d783085070f5d57..db8946cec7dcc7b61546a42488b8a25b81da0e6c 100644 (file)
--- a/openpower/sv.mdwn
+++ b/openpower/sv.mdwn
@@ -73,55 +73,6 @@ Computational Supercomputing.  The Compliancy Levels are arranged such
 that even at the bare minimum Level, full Soft-Emulation of all
 optional and future features is possible.
 
-# Major opcodes summary
-
-Please be advised that even though below is entirely DRAFT status, there
-is considerable concern that because there is not yet any two-way
-day-to-day communication established with the OPF ISA WG, we have
-no idea if any of these are conflicting with future plans by any OPF
-Members.  **The External ISA WG RFC Process is yet to be ratified
-and Libre-SOC may not join the OPF as an entity because it does
-not exist except in name. Even if it existed it would be a conflict
-of interest to join the OPF, due to our funding remit from NLnet**.
-We therefore proceed on the basis of making public the intention to
-submit RFCs once the External ISA WG RFC Process is in place and,
-in a wholly unsatisfactory manner have to *hope and trust* that
-OPF ISA WG Members are reading this and take it into consideration.
-
-**None of these Draft opcodes are intended for private custom
-secret proprietary usage. They are all intended for entirely
-public, upstream, high-profile mass-volume day-to-day usage at the
-same level as add, popcnt and fld**
-
-* SVP64 requires 25% of EXT01 (bits 6 and 9 set to 1)
-* bitmanip requires two major opcodes (due to 16+ bit immediates)
-  those are currently EXT022 and EXT05.
-* brownfield encoding in one of those two major opcodes still
-  requires multiple VA-Form operations (in greater numbers
-  than EXT04 has spare)
-* space in EXT019 next to addpcis and crops is recommended
-  (or any 5-6 bit Minor XO areas)
-* many X-Form opcodes currently in EXT022 have no preference
-  for a location at all, and may be moved to EXT059, EXT019,
-  EXT031 or other much more suitable location.
-
-Note that there is no Sandbox allocation in the published ISA Spec for
-v3.1 EXT01 usage, and because SVP64 is already 64-bit Prefixed,
-Prefixed-Prefixed-instructions (SVP64 Prefixed v3.1 Prefixed)
-would become a whopping 96-bit long instruction. Avoiding this
-situation is a high priority which in turn by necessity puts pressure
-on the 32-bit Major Opcode space.
-
-Note also that EXT022, the Official Architectural Sandbox area
-is under severe design pressure as it is insufficient to hold
-the full extent of the instruction additions required to create
-a Hybrid 3D CPU-VPU-GPU.
-
-**Whilst SVP64 is only 4 instructions
-the heavy focus on VSX for the past 12 years has left the SFFS Level
-anaemic and out-of-date compared to ARM and x86. Approximately
-100 additional Scalar Instructions are up for proposal**
-
 # Sub-pages
 
 Pages being developed and examples
@@ -220,3 +171,52 @@ Additional links:
 * [[openpower/sv/llvm]]
 * [[openpower/sv/effect-of-more-decode-stages-on-reg-renaming]]
 
+# Major opcodes summary
+
+Please be advised that even though below is entirely DRAFT status, there
+is considerable concern that because there is not yet any two-way
+day-to-day communication established with the OPF ISA WG, we have
+no idea if any of these are conflicting with future plans by any OPF
+Members.  **The External ISA WG RFC Process is yet to be ratified
+and Libre-SOC may not join the OPF as an entity because it does
+not exist except in name. Even if it existed it would be a conflict
+of interest to join the OPF, due to our funding remit from NLnet**.
+We therefore proceed on the basis of making public the intention to
+submit RFCs once the External ISA WG RFC Process is in place and,
+in a wholly unsatisfactory manner have to *hope and trust* that
+OPF ISA WG Members are reading this and take it into consideration.
+
+**None of these Draft opcodes are intended for private custom
+secret proprietary usage. They are all intended for entirely
+public, upstream, high-profile mass-volume day-to-day usage at the
+same level as add, popcnt and fld**
+
+* SVP64 requires 25% of EXT01 (bits 6 and 9 set to 1)
+* bitmanip requires two major opcodes (due to 16+ bit immediates)
+  those are currently EXT022 and EXT05.
+* brownfield encoding in one of those two major opcodes still
+  requires multiple VA-Form operations (in greater numbers
+  than EXT04 has spare)
+* space in EXT019 next to addpcis and crops is recommended
+  (or any 5-6 bit Minor XO areas)
+* many X-Form opcodes currently in EXT022 have no preference
+  for a location at all, and may be moved to EXT059, EXT019,
+  EXT031 or other much more suitable location.
+
+Note that there is no Sandbox allocation in the published ISA Spec for
+v3.1 EXT01 usage, and because SVP64 is already 64-bit Prefixed,
+Prefixed-Prefixed-instructions (SVP64 Prefixed v3.1 Prefixed)
+would become a whopping 96-bit long instruction. Avoiding this
+situation is a high priority which in turn by necessity puts pressure
+on the 32-bit Major Opcode space.
+
+Note also that EXT022, the Official Architectural Sandbox area
+is under severe design pressure as it is insufficient to hold
+the full extent of the instruction additions required to create
+a Hybrid 3D CPU-VPU-GPU.
+
+**Whilst SVP64 is only 4 instructions
+the heavy focus on VSX for the past 12 years has left the SFFS Level
+anaemic and out-of-date compared to ARM and x86. Approximately
+100 additional Scalar Instructions are up for proposal**
+