-(Draft Status)
-
# Letter regarding ISAMUX / NS
+* Revision 0.0 draft: 03 Mar 2020
+* Revision 0.1 addw review: 16 Apr 2020
+* Revision 0.9 pre-final: 18 Apr 2020
+* Revision 0.91 mention dual ISA: 22 Apr 2020
+* Revision 0.92 mention countdown idea: 22 Apr 2020
+
+## 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.
+
+## Summary
+
+* 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.
+* 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.
+* 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).
+* 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.
+
+## 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. It is based on
+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:
* FPSCR's "NI" bit, setting non-IEEE754 FP mode
* MSR's "LE" bit (and associated HILE bit), setting little-endian mode
* MSR's "SF" bit, setting either 32-bit or 64-bit mode
+* PCR's "compatibility" bits 60-62, V2.05 V2.06 V2.07 mode
+
+[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 are set by one instruction, that, once set, radically
+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) have
-a clear, standards-non-disruptive, atomic and non-intrusive path to
-extend the POWER ISA.
-
-## Overview
-
-The PowerPC Instruction Set Architecture (ISA) is an abstract model of a
-computer. This is what programmers use when they write programs for the machine,
-even if indirectly via a compiler for a high level language. We must be
-conservative in how we add to the ISA to:
-
-* not break existing programs
-* be mindful as to how others may wish to add to the ISA in the future
-
-This document describes our strategy.
-
-
-## ISA modes and escape sequences
-
-New chips usually need to be able to run older (legacy) software that is
-incompatible with the latest and greatest ISA. Eg: 64 bit chip must be able to
-run older 16 bit and 32 bit software.
-
-To enable backwards compatability the CPU will be set into 'legacy' mode. This
-is done with an ISA Mode switch, also known as ISA Muxing or ISA Namespaces.
-
-The operating system is able to quickly change between 'modern' ISA mode and
-various legacy modes.
-
-Another technique is an ISA escape-sequence. This is a type of mode that is
-only operational for a short time, unlike 32 or 64 bit which would be for the
-entire run of a program.
-
-
-## What are we adding to the ISA
-
-When high quality graphical display were developed the CPUs at the time were
-shown to not be able to run the display fast enough. The solution was the use of
-Graphics cards, these are specialised computers that are good at rendering
-pixels; often by doing the same thing in different parts of the screen at the
-same time (in parallel). These specialised computers are called Graphical
-Processing Units (GPUs).
-
-The parallelism of some GPUs is thousands. This has led to GPUs being used to
-solve non graphical problems where high parallelism is useful.
-
-**break**
-
-# Letter regarding ISAMUX / NS
-
-Hardware-level dynamic ISA Muxing (also known as ISA Namespaces and ISA
-escape-sequencing) is commonly used in instruction sets, in an arbitrary
-and ad-hoc fashion, added often on an on-demand basis. Examples include:
-
-* Setting a SPR to switch the meaning of certain opcodes for Little-Endian /
- Big-Endian behaviour (present in POWER and SPARC)
-* Setting a SPR to provide "backwards-compatibility" for features from
- older versions of an ISA (such as changing to new ratified versions of
- the IEEE754 standard)
-
-(These we term "ISA Muxing" because, ultimately, they are extra bits
-(or change existing bits) in the actual instruction decoder phase,
-which involves "MUXes" to switch them on and off).
-
-The Libre-SOC team, developing a hybrid CPU-VPU-GPU, needs to add
-significantly and strategically to the POWER ISA to support, for example,
-Khronos Vulkan IEEE754 Conformance, whilst *at the same time being able
-to run full POWER9 compliant instructions*.
-
-There is absolutely no way that we are going to duplicate the
-entire FP opcode set as a custom extension to POWER, just to add a
-literally-identical suite of FP opcodes that are compliant with the
-Khronos Conformance Suites: this would be a significant and irresponsible
-use of opcode space.
-
-In addition, as this processor is likely to be used for parallel
-compute purposes in high-efficiency environments, we also need to add
-FP16 support. Again: there is no way that we are going to add *triple*
-duplicated opcodes to POWER, given that the opcodes needed are absolutely
-identical to those that already exist, apart from the FP bitwidth (32
-/ 64).
-
-There are several other strategically critical uses to which we would
-like to put such a scheme (related to power consumption and reducing
-throughput bottlenecks needed for heavy-computation workloads in GPU
-and VPU scenarios).
-
-In addition, the scheme has several other key advantages over other ISA
-"extending" ideas (such as extending the general ISA POWER space to
-64 bit) in that, unlike 64 bit opcodes, its judicious and careful use
-does not require large increases in I-Cache size because all opcodes,
-ultimately, remain 32-bit. The scheme also allows future *official*
-POWER extensions to the ISA - managed by the OpenPOWER Foundation -
-to be strategically managed in a controlled, long-term, non-damaging
-way to the reputation and stability of OpenPOWER.
-
-Therefore we advocate being able to set "ISAMUX/NS" mode-switching bits
-that, like the *existing* LE/BE mode-switching bits, change the behaviour
-of *existing* opcodes to an alternative "meaning" (followed by another
-mode-switch that returns them to their original meaning. Note: to reduce
-binary code-size, alternative schemes include setting a countdown which,
-when it expires, automatically disables the requested mode-switch)
-
-Note also that to ensure that kernels and hypervisors are not impacted
-by userspace ISAMUX/NS mode-switching, it is critical that Supervisor
-and Hypervisor modes have their own completely separate ISAMUX/NS SPRs
-(imagine a userspace application setting the LE/BE bit on a global basis,
-or setting a global IEEE754 FP Standards compatibility flag).
-
-Further, that Supervisor / Hypervisor modes have access to and control
-over userspace ISAMUX/NS SPRs (without themselves being affected by
-setting *of* userspace ISAMUX/NS SPRs), in order to be able to correctly
-context-switch userspace applications to their correct (former) running
-state.
-
-Given the number of mode-switch bits that we anticipate using, we advocate
-that such a scheme be formalised, and that the OpenPOWER Foundation be
-the "atomic arbiter" similar to IANA and JEDEC in the formal allocation
-of mode-switch bits to OpenPOWER implementors.
-
-We envisage that some of these bits will be unary, some will be binary,
-some will be allocated for exclusive use by the OpenPOWER Foundation,
-some allocated to OpenPOWER Members (by the OpenPOWER Foundation),
-and some reserved for "custom and experimentation usage".
-
-(This latter - custom experimentation - to be explicitly documented
-that upstream compiler and toolchain support will never, under any
-circumstances be accepted by the OpenPOWER Foundation, and that this be
-enforced through the EULA and through Trademark law).
-
-
-However as we are quite new to POWER 3.0B (1300+ page PDF), we do
-appreciate that such a formal scheme may already be present in POWER9
-3.0B, that we have simply overlooked.
+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.
+
+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 (illegal instruction trap). However traps and exceptions will need to save (and restore) the counter 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).
+
+# 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:
+
+* 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.
+* 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
+* 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)
+* 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.
+* 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.
+* We cannot "go ahead anyway" because to do so would be highly irresponsible
+ and cause massive disruption to the POWER community.
+
+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 / libreriscv.git / blobdiff