From: lkcl Date: Tue, 21 Feb 2023 12:25:30 +0000 (+0000) Subject: (no commit message) X-Git-Tag: opf_rfc_ls001_v3~219 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=0ca36e889db99ff5b49c57f46b6d4e42f319308a;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn index 1f76e62d4..0665ee3c5 100644 --- 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**