(no commit message)

diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn
index 1f76e62d40d83279eeca696d9461c01c942a6f3e..0665ee3c5ef6bf3a5aad81d0fa79fbb1d3db6dcd 100644 (file)
--- a/openpower/sv/rfc/ls005.mdwn
+++ b/openpower/sv/rfc/ls005.mdwn
@@ -79,10 +79,38 @@ this with the more "normal" approach of creating heavily-focussed
 specialist "AI" Engines incapable of Turing-completeness and the benefits
 are clear.
 
-Note: SVP64 **requires** this change as a 100% critical dependency.
+Note 1: SVP64 **requires** this change as a 100% critical dependency.
 SIMD back-end ALUs process Vectors of "Elements" at 8, 16 and 32-bit (and
 64-bit), read from, processed, and returned to, the standard **Scalar**
-Register Files, with byte-level write-enable lines.
+Register Files, with byte-level write-enable lines.  The proposal is
+therefore made as an opportunity for others interested in Scalar ISA
+8/16/32-bit (and future 128-bit variants of Scalar Power ISA) to take
+**and complete** that work in an incremental fashion, without having
+to be faced with a massive bulk and body of work as a prerequisite.
+
+Examples include that whilst an SVP64 Prefixed '''lbz''' instruction
+('''sv.lbz''') is well-defined and has strict well-defined behaviour,
+a pure **Scalar-only** (non-SVP64) over-ridden '''lbz''' instruction
+has not been so well-defined, and would require a Stakeholder interested
+in 8/16/32-bit (and future 128-bit) to think through the implications
+and incrementally submit further OPF ISA RFCs.  With RISC-V **already
+having done this type of work** it is not technically difficult: it
+just requires another Stakeholder to do it.
+
+Note 2: one alternative to this proposal, as far as SVP64 is concerned,
+is to literally duplicate the entirety of Chapters 3 and 4 Book III,
+and to create - and then maintain - multiple identical copies of the
+instructions including identical copies of the pseudocode except for 
+substitution of occurrences of "64" with a "32" variant, "16" variant,
+"8" variant (and future "128" variant), and so on.  This would add
+over 700 additional pages to the Power ISA Specification and it should
+be clear that it would become a maintenance nightmare.
+
+Another alternative is to poison and irredemably damage the Power ISA
+(as a powerful and lean RISC ISA) by adding several hundred (close to 1,000) 
+additional specific 8-bit, 16-bit and 32-bit (and in future 128-bit) Scalar
+instructions. Given that the 32-bit Opcode Allocation Space is already
+under pressure such a move would be extremely unwise for that reason alone.
 
 **Changes**