**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>
**Date**: 22 Dec 2022
-**Target**: v3.2B
-
-**Source**: v3.0B
+**Target** v3.2B
**Books and Section affected**:
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**
create 16-bit, 32-bit and 64-bit addresses (depending on application need).
GPR is obvious, FPR is quirky. SVP64 redefines FP ops (those not ending in "s")
to be "full width" and all ops ending in "s" to be "half of
-the FP width".
+the full width".
* XLEN=64 keeps FPR "full width" exactly as presently defined, and
"half width" exactly as presently defined.
* XLEN=32 overrides FPR "full width" operations to
- full FP32, and "half width" to be "FP16 stored in an FP32"
-* XLEN=16 redefines FPR "full width" operations to full BFP16 and leaves
- "half width" UNDEFINED (there is no FP8).
-* XLEN=8 redefines FPR "full width" operations to BF16 and leaves
- "half width" UNDEFINED (there is no BF8).
+ full BFP32, and "half width" to be "BFP16 stored in an BFP32"
+* XLEN=16 redefines FPR "full width" operations to full [IEEE BFP16](https://en.wikipedia.org/wiki/Half-precision_floating-point_format) and leaves
+ "half width" RESERVED (there is no IEEE version of [FP8](https://web.archive.org/web/20221223085833/https://wccftech.com/nvidia-intel-arm-bet-their-ai-future-on-fp8-whitepaper-for-8-bit-fp-published/)).
+* XLEN=8 redefines FPR "full width" operations to [bfloat16](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format) and leaves
+ "half width" RESERVED.
----------------
+# 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]]
projects / libreriscv.git / blobdiff