+++ /dev/null
-%
-\chapter{Introduction}
-
-\section{Why has Libre-SOC chosen PowerPC ?}
-
-For a hybrid CPU-VPU-GPU, intended for mass-volume adoption in tablets,
-netbooks, chromebooks and industrial embedded (SBC) systems, our choice was
-between Nyuzi, MIAOW, RISC-V, PowerPC, MIPS and OpenRISC.
-
-Of all the options, the PowerPC architecture is more complete and far more
-mature. It also has a deeper adoption by Linux distributions.
-
-Following IBM's release of the Power Architecture instruction set to the Linux
-Foundation in August 2019 the barrier to using it is no more than that of using
-RISC-V. We are encouraged that the OpenPOWER Foundation is supportive of what
-we are doing and helping, e.g by putting us in touch with people who can help
-us.
-
-\subsection{Summary}
-
-\vspace{-0.1in}
-\begin{itemize}
-\parskip 0pt
-\itemsep 1pt
-
-\item
- We propose the standardisation of the way that the PowerPC Instruction Set
- Architecture (PPC ISA) is extended, enabling many different flavours within a
- well supported family to co-exist, long-term, without conflict, right across
- the board.
-
-\item
-
- This is about more than just our project. Our proposals will facilitate the
- use of PPC in novel or niche applications without breaking the PPC ISA into
- incompatible islands.
-
-\item
-
- PPC will gain a competitive market advantage by removing the need for
- separate VPU or GPU functions in RTL or ASICs thus enabling lower cost
- systems. Libre-SOC's project is to extend the PPC to integrate the GPU and
- VPU functionality directly as part of the PPC ISA (example: Broadcom
- VideoCore IV being based around extensions to an ARC core).
-
-\item
-
- Libre-SOC's extensions will be easily adopted, as the standard GNU/Linux
- distributions will very deliberately run unmodified on our ISA, including
- full compatibility with illegal instruction trap requirements.
-
-\end{itemize}
-
-
-\subsection{One CPU multiple ISAs}
-
-This is a quick overview of the way that we would like to add changes that we
-are proposing to the PowerPC instruction set (ISA). It is based on a Open
-Standardisation of the way that existing "mode switches", already found in the
-POWER instruction set, are added:
-
-\begin{itemize}
-\parskip 0pt
-\itemsep 1pt
-
-\item
-
- FPSCR's "NI" bit, setting non-IEEE754 FP mode
-
-\item
-
- MSR's "LE" bit (and associated HILE bit), setting little-endian mode
-
-\item
-
- MSR's "SF" bit, setting either 32-bit or 64-bit mode
-
-\item
-
- PCR's "compatibility" bits 60-62, V2.05 V2.06 V2.07 mode
-
-\end{itemize}
-
-[It is well-noted that unless each "mode switch" bit is set, any alternative
-(additional) instructions (and functionality) are completely inaccessible, and
-will result in "illegal instruction" traps being thrown. This is recognised as
-being critically important.]
-
-These bits effectively create multiple, incompatible run-time switchable ISAs
-within one CPU. They are selectable for the needs of the individual program (or
-OS) being run.
-
-All of these bits are set by an instruction, that, once set, radically changes
-the entire behaviour and characteristics of subsequent instructions.
-
-With these (and other) long-established precedents already in POWER, there is
-therefore essentially conceptually nothing new about what we propose: we simply
-seek that the process by which such "switching" is added is formalised and
-standardised, such that we (and others, including IBM itself) have a clear,
-well-defined standards-non-disruptive, atomic and non-intrusive path to extend
-the POWER ISA for use in markets that it presently cannot enter.
-
-We advocate that some of "mode-setting" (escape-sequencing) bits be binary
-encoded, some unary encoded, and that some space marked for "offical" use, some
-"experimental", some "custom" and some "reserved". The available space in a
-suitably-chosen SPR to be formalised, and recommend the OpenPOWER Foundation be
-given the IANA-like role in atomically allocating mode bits.
-
-The IANA-like atomic role ensures that new PCR mode bits are allocated
-world-wide unique. In combination with a mandatory illegal instruction
-exception to be thrown on any system not supporting any given mode, the
-opportunity exists for all systems to trap and emulate all other systems and
-thus retain some semblance of interoperability. (Contrast this with either
-allocating the same mode bit(s) to two (or more) designers, or not making
-illegal exceptions mandatory: binary interoperability becomes unachievable and
-the result is irrevocable damage to POWER's reputation.)
-
-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.
-
-Instructions that we need to add, which are a normal part of GPUs, include
-ATAN2, LOG, NORMALISE, YUV2RGB, Khronos Compliance FP mode (different from both
-IEEE754 and "NI" mode), and many more. Many of these may turn out to be useful
-in a wider context: they however need to be fully isolated behind
-"mode-setting" before being in any way considered for Standards-track formal
-adoption.
-
-Some mode-setting instructions are privileged, i.e can only be set by the
-kernel (e.g 32 or 64 bit mode). Most of the escape sequences that we propose
-will be (have to be) usable without the need for an expensive system call
-overhead (because some of the instructions needed will be in extremely tight
-inner loops).
-
-\subsection{About Libre-SOC Commercial Project}
-
-The Libre-SOC Commercial Product is a hybrid GPU-GPU-VPU intended for
-mass-volume production. There is no separate GPU, because the CPU is the GPU.
-There is no separate VPU, because the CPU is the GPU. There is not even a
-separate pipeline: the CPU pipelines are the GPU and VPU pipelines.
-
-Closest equivalents include the ARC core (which has VPU extensions and 3D
-extensions in the form of Broadcom's VideoCore IV) and the ICubeCorp IC3128.
-Both are considered "hybrid" CPU-GPU-VPU processors.
-
-"Normal" Commercial GPUs are entirely separate processors. The development cost
-and complexity purely in terms of Software Drivers alone is immense. We reject
-that approach (and as a small team we do not have the resources anyway).
-
-With the project being Libre - not proprietary and secretive and never to be
-published, ever - it is no good having the extensions as "custom" because
-"custom" is specifically for the cases where the augmented toolchain is never,
-under any circumstances, published and made public by the proprietary company
-(and would never be accepted upstream anyway). For business commercial reasons,
-Libre-SOC is the total opposite of this proprietary, secretive approach.
-
-Therefore, to meet our business objectives:
-
-\begin{itemize}
-\parskip 0pt
-\itemsep 1pt
-
-\item
-
- As shown from Nyuzi and Larrabee, although ideally suited to high
- performance compute tasks, a "traditional" general-purpose full
- IEEE754-compliant Vector ISA (such as that in POWER9) is not an adequate
- basis for a commercially competitive GPU. Nyuzi's conclusion is that using
- such general-purpose Vector ISAs results in reaching only 25% performance
- (or requiring 4-fold increase in power consumption) to achieve par with
- current commercial-grade GPUs.
-
-\item
-
- We are not going the "traditional" (separate custom GPU) route because it
- is not practical for a new team to design hardware and spend 8+ man-years
- on massively complex inter-processor driver development as well
-
-\item
-
- We cannot meet our objectives with a "custom extension" because the
- financial burden on our team to maintain a total hard fork of not just
- toolchains, but also entire GNU/Linux Distros, is highly undesirable, and
- completely impractical (we know for certain that Redhat would strongly
- object to any efforts to hard-fork Fedora)
-
-\item
-
- 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.
-
-\item
-
- 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.
-
-\item
-
- We cannot "go ahead anyway" because to do so would be highly irresponsible
- and cause massive disruption to the POWER community.
-
-\end{itemize}
-
-With all impractical options eliminated the only remaining responsible option
-is to extend the POWER ISA in an atomically-managed (IANA-style) formal
-fashion, whilst (critically and absolutely essentially) always providing a PCR
-compatibility mode that is fully POWER compliant, including all illegal
-instruction traps.
-
-
projects / libresoc-isa-manual.git / blobdiff