Bring into sync
[libresoc-isa-manual.git] / powerpc-add / src / intro.tex
1 %
2 \chapter{Introduction}
4 \section{Why has Libre-SOC chosen PowerPC ?}
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.
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.
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.
19 \subsection{Summary}
21 \vspace{-0.1in}
22 \begin{itemize}
23 \parskip 0pt
24 \itemsep 1pt
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.
32 \item
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.
38 \item
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).
46 \item
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.
52 \end{itemize}
55 \subsection{One CPU multiple ISAs}
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:
62 \begin{itemize}
63 \parskip 0pt
64 \itemsep 1pt
66 \item
68 FPSCR's "NI" bit, setting non-IEEE754 FP mode
70 \item
72 MSR's "LE" bit (and associated HILE bit), setting little-endian mode
74 \item
76 MSR's "SF" bit, setting either 32-bit or 64-bit mode
78 \item
80 PCR's "compatibility" bits 60-62, V2.05 V2.06 V2.07 mode
82 \end{itemize}
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.]
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.
93 All of these bits are set by an instruction, that, once set, radically changes
94 the entire behaviour and characteristics of subsequent instructions.
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.
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.
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.)
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.
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.
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).
139 \subsection{About Libre-SOC Commercial Project}
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.
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.
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).
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.
161 Therefore, to meet our business objectives:
163 \begin{itemize}
164 \parskip 0pt
165 \itemsep 1pt
167 \item
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.
177 \item
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
183 \item
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)
191 \item
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.
199 \item
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.
204 \item
206 We cannot "go ahead anyway" because to do so would be highly irresponsible
207 and cause massive disruption to the POWER community.
209 \end{itemize}
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.