openpower/sv/rfc/ls005.mdwn

   1 # OPF ISA WG External RFC ls005 v1: XLEN
   2
   3 * RFC Author: Luke Kenneth Casson Leighton.
   4 * RFC Contributors/Ideas: Jacob Lifshay, Toshaan Bharvani
   5 * Funded by NLnet under the NGI Zero Entrust EU Horizon Europe Grant 101069594
   6
   7 **URLs**:
   8
   9 * <https://libre-soc.org/openpower/sv/rfc/ls005/>
  10 * <https://bugs.libre-soc.org/show_bug.cgi?id=663>
  11 * <https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=openpower/isa;hb=HEAD>
  12 * <https://git.openpower.foundation/isa/PowerISA/issues/104>
  13
  14 **Severity**: Major
  15
  16 **Status**: New
  17
  18 **Date**: 22 Dec 2022
  19
  20 **Target** v3.2B
  21
  22 **Books and Section affected**:
  23
  24 ```
  25     Everything (in a consistent, regular and systematic fashion)
  26 ```
  27
  28 **Summary**
  29
  30 ```
  31     Exactly as is already done in RISC-V, convert the entire use of 64-bit hard-coding to "XLEN".
  32     Exactly as is in RISC-V, options then include PowerISA-32, PowerISA-64 and PowerISA-128.
  33     Unlike in RISC-V, the concept of PowerISA-16 and PowerISA-8 is also floated, for Embedded,
  34     AI, Edge, Processing-in-Memory, Distributed Computing and other purposes.
  35 ```
  36
  37 **Submitter**: Luke Leighton (Libre-SOC)
  38
  39 **Requester**: Libre-SOC
  40
  41 **Impact on processor**:
  42
  43 ```
  44     Entirely new processors, entirely new markets.
  45 ```
  46
  47 **Impact on software**:
  48
  49 ```
  50     Massive but regular, consistent, and systematic.
  51 ```
  52
  53 **Keywords**:
  54
  55 ```
  56     XLEN
  57 ```
  58
  59 **Motivation**
  60
  61 The Power ISA is far too massive, making it wholly unsuited for Embedded
  62 markets and adversely impacting its reach and potential.  The RISC paradigm
  63 it is based on has gone too far into PackedSIMD (128-bit).  Fixing this is
  64 relatively and conceptually straightforward: allow 32-bit and even 16-bit
  65 and 8-bit implementations, and use the opportunity to allow future Scalar
  66 128-bit implementations in the exact same strategic way that RISC-V has RV128.
  67
  68 Register files are redefined to XLEN width but are permitted to "group"
  69 registers together to create 16-bit, 32-bit and 64-bit addresses.
  70 In this way, the limitations of what would otherwise restrict the usefulness
  71 of a severely-targetted application-specific processor may be overcome in
  72 order to make it still possible to (at reduced performance) still run
  73 general-purpose applications.
  74 AI application-specific processing or other Processing-In-Memory or other
  75 specialist design therefore may for example focus a balance
  76 of raw computing power heavily onto 8-bit or 16-bit computation, but still
  77 gain the benefit of the Power ISA and everything it brings.  Contrast
  78 this with the more "normal" approach of creating heavily-focussed
  79 specialist "AI" Engines incapable of Turing-completeness and the benefits
  80 are clear.
  81
  82 Note: SVP64 **requires** this change as a 100% critical dependency.
  83 SIMD back-end ALUs process Vectors of "Elements" at 8, 16 and 32-bit (and
  84 64-bit), read from, processed, and returned to, the standard **Scalar**
  85 Register Files, with byte-level write-enable lines.
  86
  87 **Changes**
  88
  89 For all pseudocode right across the board in all Scalar operations, replace
  90 hard-coded "64" with "XLEN".  **This work is already underway as sponsored
  91 by NLnet in the Libre-SOC Power ISA Pseudocode**.  The default is obviously
  92 recommended to be "XLEN=64" in order to create zero disruption.
  93
  94 Definitions of the Register File(s) for GPR and FPR are then changed to be
  95 "XLEN" wide.  However, for Embedded purposes (XLEN=32/16/8), an SPR controls
  96 whether (and how many) sequentially-grouped registers are taken together to
  97 create 16-bit, 32-bit and 64-bit addresses (depending on application need).
  98 GPR is obvious, FPR is quirky.  SVP64 redefines FP ops (those not ending in "s")
  99 to be "full width" and all ops ending in "s" to be "half of
 100 the full width".
 101
 102 * XLEN=64 keeps FPR "full width" exactly as presently defined, and
 103   "half width" exactly as presently defined.
 104 * XLEN=32 overrides FPR "full width" operations to
 105   full BFP32, and "half width" to be "BFP16 stored in an BFP32"
 106 * XLEN=16 redefines FPR "full width" operations to full [IEEE BFP16](https://en.wikipedia.org/wiki/Half-precision_floating-point_format) and leaves
 107   "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/)).
 108 * XLEN=8 redefines FPR "full width" operations to [bfloat16](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format) and leaves
 109   "half width" RESERVED.
 110
 111 ----------------
 112
 113 \newpage{}