powerpc-add/src/intro.tex

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