\itemsep 1pt
\item
- We propose the standardisation of the way that the PowerPC Instruction Set
+ We propose the standardisation of the way that the \gls{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.
\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
+Standardisation of the way that existing \textbf{mode switches}, already found in the
POWER instruction set, are added:
\begin{itemize}
\item
- FPSCR's "NI" bit, setting non-IEEE754 FP mode
+ FPSCR's \textbf{NI} bit, setting non-\gls{IEEE754} FP mode
\item
- MSR's "LE" bit (and associated HILE bit), setting little-endian mode
+ MSR's \textbf{LE} bit (and associated HILE bit), setting little-endian mode
\item
- MSR's "SF" bit, setting either 32-bit or 64-bit mode
+ MSR's \textbf{SF} bit, setting either 32-bit or 64-bit mode
\item
- PCR's "compatibility" bits 60-62, V2.05 V2.06 V2.07 mode
+ PCR's \textbf{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
+[It is well-noted that unless each \textbf{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
+will result in \textbf{illegal instruction} traps being thrown. This is recognised as
being critically important.]
These bits effectively create multiple, incompatible run-time switchable ISAs
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
+seek that the process by which such \textbf{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
+We advocate that some of \textbf{mode-setting} (escape-sequencing) bits be binary
+encoded, some unary encoded, and that some space marked for \textbf{offical} use, some
+\textbf{experimental}, some \textbf{custom} and some \textbf{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.
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
+We also advocate to consider reserving some bits as a \textbf{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
+explicit need to \textbf{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
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
+IEEE754 and \textbf{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
+\textbf{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
\subsection{About Libre-SOC Commercial Project}
-The Libre-SOC Commercial Product is a hybrid GPU-GPU-VPU intended for
+The Libre-SOC Commercial Product is a hybrid \gls{CPU}-\gls{GPU}-\gls{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.
+Both are considered \textbf{hybrid} CPU-GPU-VPU processors.
-"Normal" Commercial GPUs are entirely separate processors. The development cost
+\textbf{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,
+published, ever - it is no good having the extensions as \textbf{custom} because
+\textbf{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.
\item
As shown from Nyuzi and Larrabee, although ideally suited to high
- performance compute tasks, a "traditional" general-purpose full
+ performance compute tasks, a \textbf{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
\item
- We are not going the "traditional" (separate custom GPU) route because it
+ We are not going the \textbf{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
+ We cannot meet our objectives with a \textbf{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
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
+ to switch over to that \textbf{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.
+ Inter-Processor Bus Architecture like on \textbf{traditional} GPUs.
\item
\item
- We cannot "go ahead anyway" because to do so would be highly irresponsible
+ We cannot \textbf{go ahead anyway} because to do so would be highly irresponsible
and cause massive disruption to the POWER community.
\end{itemize}
projects / libresoc-isa-manual.git / blobdiff