(no commit message)

diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn
index b596be280402662a502ddd7bb622d0bf876d40b5..a7f5f2dd951f1a9a6817885f322dfbce815fd48d 100644 (file)
--- a/openpower/sv.mdwn
+++ b/openpower/sv.mdwn
@@ -126,7 +126,7 @@ Core SVP64 instructions:
 Beyond this point are additional **Scalar** instructions related to
 specific workloads that have nothing to do with the SV Specification*
 
-# Non-Simple-V Scalar instructions
+# Optional Scalar instructions
 
 **Additional Instructions for specific purposes (not SVP64)**
 
@@ -198,7 +198,7 @@ opcode space is required**.  Even though they are currently
 placed in the EXT022 Sandbox, the "Management" instructions
 (setvl, svstep, svremap, svshape, svindex) are designed to fit
 cleanly into EXT019 (like `addpcis`) or other 5/6-bit Minor
-XO area.
+XO area that has space for Rc=1.
 
 That said: for the target workloads for which Scalable Vectors are typically
 used, the Scalar ISA on which those workloads critically rely
@@ -223,7 +223,7 @@ OPF ISA WG Members are reading this and take it into consideration.
 
 **Scalar Summary**
 
-As above sections, it is emphasised strongly that Simple-V in no
+As in above sections, it is emphasised strongly that Simple-V in no
 way critically depends on the 100 or so *Scalar* instructions also
 being developed by Libre-SOC.
 
@@ -242,11 +242,12 @@ same level as add, popcnt and fld**
 * 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.
-* even if ratified and even if the majority (X-Form)
-  is moved to other locations the large immediate sizes of 
+* even if ratified and even if the majority (mostly X-Form)
+  is moved to other locations, the large immediate sizes of 
   the remaining bitmanip instructions means
-  it would be highly likely they would need two
-  major opcodes.  Fortunately EXT005 and EXT009 are
+  it would be highly likely these remaining instructions would need two
+  major opcodes.  Fortuitously the v3.1 Spec states that
+  both EXT005 and EXT009 are
   available.
 
 **Additional observations**
@@ -261,22 +262,27 @@ on the 32-bit Major Opcode space.
 SVP64 itself is already under pressure, being only 24 bits.  If it is
 not permitted to take up 25% of EXT001 then it would have to be proposed
 in its own Major Opcode, which on first consideration would be beneficial
-for SVP64. However when combined with the bitmanip scalar instructions
+for SVP64 due to the availability of 2 extra bits.
+However when combined with the bitmanip scalar instructions
 requiring two Major opcodes this would come to a grand total of 3 precious
 Major opcodes. On balance, then, sacrificing 25% of EXT001 is the "least
 difficult" choice.
 
 Note also that EXT022, the Official Architectural Sandbox area
+available for "Custom non-approved purposes" according to the Power
+ISA Spec,
 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 5 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. This is partially
-a blessing as the Scalar ISA has remained clean. Approximately
+anaemic and out-of-date compared to ARM and x86.**
+This is very much
+a blessing, as the Scalar ISA has remained clean, making it
+highly suited to RISC-paradigm Scalable Vector Prefixing. Approximately
 100 additional (optional) Scalar Instructions are up for proposal to bring SFFS
-up-to-date**
+up-to-date
 
 # Other