From 0ca36e889db99ff5b49c57f46b6d4e42f319308a Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 21 Feb 2023 12:25:30 +0000 Subject: [PATCH] --- openpower/sv/rfc/ls005.mdwn | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) 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** -- 2.30.2