-(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,
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 will facilitate the use of PPC in novel or niche applications
- without breaking the PPC ISA into incompatible islands. This is about
- more than just our project.
-* Libre-SOC's project is to extend the PPC to integrate GPU and VPU
- functionality directly as part of the PPC ISA (example: Broadcom
- VideoCore IV being based around extensions to an ARC core). By not
- needing separate VPU or GPU RTL or ASICs this will enable lower cost
- systems to be built so giving PPC a competitive market advantage.
+* 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 requirements.
+ including full compatibility with illegal instruction trap requirements.
## One CPU multiple ISAs
* 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, the
-alternative instructions (and functionality) are completely inaccessible,
-and will result in "illegal instruction" traps being thrown. This is
-recognised as being critically important.
+[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 being run.
+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 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, some "offical", some "experimental" 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
+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".
+to be fully isolated behind "mode-setting" before being in any way
+considered for Standards-track formal adoption.
-Some mode-setting instructions are privileged, ie can only be set by
-the kernel (eg 32 or 64 bit mode). 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).
+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
* 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 (and Redhat would strongly object anyway)
+ 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.
projects / libreriscv.git / blobdiff