%
\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.


