openpower/isans_letter.mdwn

   1 # Letter regarding ISAMUX / NS
   2
   3 * [Full revision history](https://git.libre-soc.org/?p=libreriscv.git;a=history;f=openpower/isans_letter.mdwn)
   4 * Revision 0.0 draft: 03 Mar 2020
   5 * Revision 0.1 addw review: 16 Apr 2020
   6 * Revision 0.9 pre-final: 18 Apr 2020
   7 * Revision 0.91 mention dual ISA: 22 Apr 2020
   8 * Revision 0.92 mention countdown idea: 22 Apr 2020
   9
  10 ## Why has Libre-SOC chosen PowerPC ?
  11
  12 For a hybrid CPU-VPU-GPU, intended for mass-volume adoption in tablets,
  13 netbooks, chromebooks and industrial embedded (SBC) systems, our choice
  14 was between Nyuzi, MIAOW, RISC-V, PowerPC, MIPS and OpenRISC.
  15
  16 Of all the options, the PowerPC architecture is more complete and far more
  17 mature.  It also has a deeper adoption by Linux distributions.
  18
  19 Following IBM's release of the Power Architecture instruction set to the
  20 Linux Foundation in August 2019 the barrier to using it is no more than
  21 that of using RISC-V.  We are encouraged that the OpenPOWER Foundation is
  22 supportive of what we are doing and helping, e.g by putting us in touch
  23 with people who can help us.
  24
  25 ## Summary
  26
  27 * We propose the standardisation of the way that the PowerPC Instruction
  28   Set Architecture (PPC ISA) is extended, enabling many different flavours
  29   within a well supported family to co-exist, long-term, without conflict,
  30   right across the board.
  31 * This is about more than just our project. Our proposals will facilitate
  32   the use of PPC in novel or niche applications without breaking the PPC
  33   ISA into incompatible islands.
  34 * PPC will gain a competitive market advantage by removing the need
  35   for separate VPU or GPU functions in RTL or ASICs thus enabling lower
  36   cost systems.  Libre-SOC's project is to extend the PPC to integrate
  37   the GPU and VPU functionality directly as part of the PPC ISA (example:
  38   Broadcom VideoCore IV being based around extensions to an ARC core).
  39 * Libre-SOC's extensions will be easily adopted, as the standard GNU/Linux
  40   distributions will very deliberately run unmodified on our ISA,
  41   including full compatibility with illegal instruction trap requirements.
  42
  43 ## One CPU multiple ISAs
  44
  45 This is a quick overview of the way that we would like to add changes
  46 that we are proposing to the PowerPC instruction set (ISA).  It is based on
  47 a Open Standardisation of the way that existing "mode switches",
  48 already found in the POWER instruction set, are added:
  49
  50 * FPSCR's "NI" bit, setting non-IEEE754 FP mode
  51 * MSR's "LE" bit (and associated HILE bit), setting little-endian mode
  52 * MSR's "SF" bit, setting either 32-bit or 64-bit mode
  53 * PCR's "compatibility" bits 60-62, V2.05 V2.06 V2.07 mode
  54
  55 [It is well-noted that unless each "mode switch" bit is set, any
  56 alternative (additional) instructions (and functionality) are completely
  57 inaccessible, and will result in "illegal instruction" traps being thrown.
  58 This is recognised as being critically important.]
  59
  60 These bits effectively create multiple, incompatible run-time switchable ISAs
  61 within one CPU.  They are selectable for the needs of the individual
  62 program (or OS) being run.
  63
  64 All of these bits are set by an instruction, that, once set, radically
  65 changes the entire behaviour and characteristics of subsequent instructions.
  66
  67 With these (and other) long-established precedents already in POWER,
  68 there is therefore essentially conceptually nothing new about what we
  69 propose: we simply seek that the process by which such "switching" is
  70 added is formalised and standardised, such that we (and others, including
  71 IBM itself) have a clear, well-defined standards-non-disruptive, atomic
  72 and non-intrusive path to extend the POWER ISA for use in markets that
  73 it presently cannot enter.
  74
  75 We advocate that some of "mode-setting" (escape-sequencing) bits be
  76 binary encoded, some unary encoded, and that some space marked for
  77 "offical" use, some "experimental", some "custom" and some "reserved".
  78 The available space in a suitably-chosen SPR to be formalised, and
  79 recommend the OpenPOWER Foundation be given the IANA-like role in
  80 atomically allocating mode bits.
  81
  82 We also advocate to consider reserving some bits as a "countdown" where the new mode will be enabled only for a certain *number* of instructions. This avoids an explicit need to "flip back", reducing binary code size. Note that it is not a good idea to let the counter cross a branch or other change in PC (and to throw illegal instruction trap if attempted). However traps and exceptions themselves will need to save (and restore) the countdown, just as the rest of the PCR and other modeswitching bits need to be saved.
  83
  84 Instructions that we need to add, which are a normal part of GPUs,
  85 include ATAN2, LOG, NORMALISE, YUV2RGB, Khronos Compliance FP mode
  86 (different from both IEEE754 and "NI" mode), and many more.  Many of
  87 these may turn out to be useful in a wider context: they however need
  88 to be fully isolated behind "mode-setting" before being in any way
  89 considered for Standards-track formal adoption.
  90
  91 Some mode-setting instructions are privileged, i.e can only be set by
  92 the kernel (e.g 32 or 64 bit mode). Most of the escape sequences that we
  93 propose will be (have to be) usable without the need for an expensive
  94 system call overhead (because some of the instructions needed will be
  95 in extremely tight inner loops).
  96
  97 # About Libre-SOC Commercial Project
  98
  99 The Libre-SOC Commercial Product is a hybrid GPU-GPU-VPU intended for
 100 mass-volume production.  There is no separate GPU, because the CPU
 101 *is* the GPU.  There is no separate VPU, because the CPU *is* the GPU.
 102 There is not even a separate pipeline: the CPU pipelines *are* the
 103 GPU and VPU pipelines.
 104
 105 Closest equivalents include the ARC core (which has VPU extensions and
 106 3D extensions in the form of Broadcom's VideoCore IV) and the ICubeCorp
 107 IC3128.  Both are considered "hybrid" CPU-GPU-VPU processors.
 108
 109 "Normal" Commercial GPUs are entirely separate processors.  The development
 110 cost and complexity purely in terms of Software Drivers alone is immense.
 111 We reject that approach (and as a small team we do not have the resources
 112 anyway).
 113
 114 With the project being Libre - not proprietary and secretive and never
 115 to be published, ever - it is no good having the extensions as "custom"
 116 because "custom" is specifically for the cases where the augmented
 117 toolchain is never, under any circumstances, published and made public by
 118 the proprietary company (and would never be accepted upstream anyway).
 119 For business commercial reasons, Libre-SOC is the total opposite of this
 120 proprietary, secretive approach.
 121
 122 Therefore, to meet our business objectives:
 123
 124 * As shown from Nyuzi and Larrabee, although ideally suited to high
 125   performance compute tasks, a "traditional" general-purpose full
 126   IEEE754-compliant Vector ISA (such as that in POWER9) is not an adequate
 127   basis for a commercially competitive GPU.  Nyuzi's conclusion is that
 128   using such general-purpose Vector ISAs results in reaching only 25%
 129   performance (or requiring 4-fold increase in power consumption) to
 130   achieve par with current commercial-grade GPUs.
 131 * We are not going the "traditional" (separate custom GPU) route because
 132   it is not practical for a new team to design hardware and spend 8+
 133   man-years on massively complex inter-processor driver development as well
 134 * We cannot meet our objectives with a "custom extension" because the
 135   financial burden on our team to maintain a total hard fork of not just
 136   toolchains, but also entire GNU/Linux Distros, is highly undesirable,
 137   and completely impractical (we know for certain that Redhat would
 138   strongly object to any efforts to hard-fork Fedora)
 139 * We could invent our own custom GPU instruction set (or use and extend an existing one, to save a man-decade on toolchain development) however even to switch over to that "Dual ISA" GPU instruction set in the next clock cycle *still requires a PCR modeswitch bit* in order to avoid needing a full Inter-Processor Bus Architecture like on "traditional" GPUs.
 140 * If extending any instruction set, rather than have a Dual ISA (which needs the PCR modeswitch bit to access it) we would rather extend POWER.
 141 * We cannot "go ahead anyway" because to do so would be highly irresponsible
 142   and cause massive disruption to the POWER community.
 143
 144 With all impractical options eliminated the only remaining responsible
 145 option is to extend the POWER ISA in an atomically-managed (IANA-style)
 146 formal fashion, whilst (critically and absolutely essentially) always
 147 providing a PCR compatibility mode that is fully POWER compliant, including
 148 all illegal instruction traps.
 149