add LS005 RFC

diff --git a/openpower/sv/rfc/Makefile b/openpower/sv/rfc/Makefile
index 7f39f8fb4a05568bb20e2c927973c344af33fea6..804c854ee0a6c8d2fc2dc708960f51eea81a0f79 100644 (file)
--- a/openpower/sv/rfc/Makefile
+++ b/openpower/sv/rfc/Makefile
@@ -1,4 +1,4 @@
-all: ls001.pdf ls002.pdf ls003.pdf
+all: ls001.pdf ls002.pdf ls003.pdf ls004.pdf ls005.pdf
 
 %.pdf: %.mdwn
        pandoc \

diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn
new file mode 100644 (file)
index 0000000..7f84298
--- /dev/null
+++ b/openpower/sv/rfc/ls005.mdwn
@@ -0,0 +1,102 @@
+# OPF ISA WG External RFC ls005 v1: XLEN
+
+* RFC Author: Luke Kenneth Casson Leighton.
+* RFC Contributors/Ideas: Jacob Lifshay, Toshaan Bharvani
+* Funded by NLnet under the NGI Zero Entrust EU Horizon Europe Grant 101069594
+
+**URLs**:
+
+* <https://libre-soc.org/openpower/sv/rfc/ls005/>
+* <https://bugs.libre-soc.org/show_bug.cgi?id=671>
+* <https://bugs.libre-soc.org/show_bug.cgi?id=663>
+* <https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=openpower/isa;hb=HEAD>
+
+**Severity**: Major
+
+**Status**: New
+
+**Date**: 22 Dec 2022
+
+**Target**: v3.2B
+
+**Source**: v3.0B
+
+**Books and Section affected**:
+
+```
+    Everything (in a consistent, regular and systematic fashion)
+```
+
+**Summary**
+
+```
+    Exactly as is already done in RISC-V, convert the entire
+    use of 64-bit hard-coding to "XLEN".  Exactly as is in RISC-V,
+    options then include PowerISA-32, PowerISA-64 and PowerISA-128.
+    Unlike in RISC-V, the concept of PowerISA-16 and PowerISA-8 is
+    also floated, for Embedded, AI, Edge, Processing-in-Memory,
+    Distributed Computing and other purposes.
+```
+
+**Submitter**: Luke Leighton (Libre-SOC)
+
+**Requester**: Libre-SOC
+
+**Impact on processor**:
+
+```
+    Entirely new processors, entirely new markets.
+```
+
+**Impact on software**:
+
+```
+    Massive but regular, consistent, and systematic.
+```
+
+**Keywords**:
+
+```
+    XLEN
+```
+
+**Motivation**
+
+The Power ISA is far too massive, making it wholly unsuited for Embedded
+markets and adversely impacting its reach and potential.  The RISC paradigm
+it is based on has gone too far into PackedSIMD (128-bit).  Fixing this is
+relatively and conceptually straightforward: allow 32-bit and even 16-bit
+and 8-bit implementations, and use the opportunity to allow future Scalar
+128-bit implementations in the exact same strategic way that RISC-V has RV128.
+
+Register files are redefined to XLEN width but are permitted to "group"
+registers together to create 16-bit, 32-bit and 64-bit addresses.
+In this way, the limitations of what would otherwise restrict the usefulness
+of a severely-targetted application-specific processor may be overcome in
+order to make it still possible to (at reduced performance) still run
+general-purpose applications.
+
+AI application-specific processing or other Processing-In-Memory or other
+specialist design therefore may for example focus a balance
+of raw computing power heavily onto 8-bit or 16-bit computation, but still
+gain the benefit of the Power ISA and everything it brings.  Contrast
+this with the more "normal" approach of creating heavily-focussed
+specialist "AI" Engines incapable of Turing-completeness and the benefits
+are clear.
+
+**Changes**
+
+For all pseudocode right across the board in all Scalar operations, replace
+hard-coded "64" with "XLEN".  **This work is already underway as sponsored
+by NLnet in the Libre-SOC Power ISA Pseudocode**.  The default is obviously
+recommended to be "XLEN=64" in order to create zero disruption.
+
+Definitions of the Register File(s) for GPR and FPR are then changed to be
+"XLEN" wide.  However, for Embedded purposes (XLEN=32/16/8), an SPR controls
+whether (and how many) sequentially-grouped registers are taken together to
+create 16-bit, 32-bit and 64-bit addresses (depending on application need).
+
+----------------
+
+\newpage{}
+