-
# Letter regarding ISAMUX / NS
-* Revision 1.0: Sat 18 Apr 2020
+* [Full revision history](https://git.libre-soc.org/?p=libreriscv.git;a=history;f=openpower/isans_letter.mdwn)
+* 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
+* Revision 0.93 illegal instruction trap: 27 Apr 2020
## Why has Libre-SOC chosen PowerPC ?
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".
+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). Most of the escape sequences that we
+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).
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.
projects / libreriscv.git / blobdiff