ls008 only doing setvl and svstep

[libreriscv.git] / openpower / sv / rfc / ls005.mdwn

diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn
index f19cf7fc5c9f9799e98135198ee9ed1e52883a35..9628dcf9f62ef79836db3ab54753d53519e81bd9 100644 (file)
--- a/openpower/sv/rfc/ls005.mdwn
+++ b/openpower/sv/rfc/ls005.mdwn
@@ -7,7 +7,7 @@
 **URLs**:
 
 * <https://libre-soc.org/openpower/sv/rfc/ls005/>
-* <https://bugs.libre-soc.org/show_bug.cgi?id=663>
+* <https://bugs.libre-soc.org/show_bug.cgi?id=988>
 * <https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=openpower/isa;hb=HEAD>
 * <https://git.openpower.foundation/isa/PowerISA/issues/104>
 
@@ -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**
 
@@ -110,4 +138,33 @@ the full width".
 
 ----------------
 
+# Examples
+
+add pseudocode examples demonstrating modification.
+
+before for popcntb:
+
+```
+do i = 0 to 7
+   n <-  0
+   do j = 0 to 7
+      if (RS)[(i*8)+j] = 1 then
+          n <- n+1
+   RA[(i*8):(i*8)+7] <-  n
+```
+
+after:
+
+```
+do i = 0 to ((XLEN/8)-1)
+   n <-  0
+   do j = 0 to 7
+      if (RS)[(i*8)+j] = 1 then
+          n <- n+1
+   RA[(i*8):(i*8)+7] <-  n
+```
+
+
 \newpage{}
+
+[[!tag opf_rfc]]