update isans letter

diff --git a/openpower/isans_letter.mdwn b/openpower/isans_letter.mdwn
index ec83077329a18428864d186efc99e0c7403434d4..2ee0499f86b98f6efde5dece9b46452bb043de5e 100644 (file)
--- a/openpower/isans_letter.mdwn
+++ b/openpower/isans_letter.mdwn
@@ -2,12 +2,38 @@
 
 # Letter regarding ISAMUX / NS
 
-## Summary of the Libre-SOC project
+## 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 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.
+* 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.
 
-* We propose a standard way of extending the PowerPC Instruction Set Architecture (PPC ISA) enabling many different individuals within a well supported family.
-* 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 into the PPC ISA. By not needing separate chips this will enable lower cost systems to be built so giving PPC a competitive market advantage.
-* Libre-SOC's extensions will be easily adopted as the standard Linux distributions will run on our ISA without needing any extra work.
+## 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.
 
 ## One CPU multiple ISAs
 
@@ -21,7 +47,14 @@ already found in the POWER instruction set, are added:
 * 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
 
-These effectively create multiple, incompatible ISAs within one CPU. They are selectable for the needs of the individual program being run.
+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.
+
+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.
 
 All of these are set by one instruction, that, once set, radically
 changes the entire behaviour and characteristics of subsequent instructions.
@@ -36,8 +69,8 @@ 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 the OpenPOWER Foundation to be given an IANA-like role in atomically
-allocating mode bits.
+and recommend the OpenPOWER Foundation be given the IANA-like role in
+atomically allocating mode bits.
 
 Instructions that we need to add, which are a normal part of GPUs,
 include ATAN2, LOG, NORMALISE, YUV2RGB, Khronos Compliance FP mode
@@ -45,7 +78,11 @@ include ATAN2, LOG, NORMALISE, YUV2RGB, Khronos Compliance FP mode
 these may turn out to be useful in a wider context: they however need
 to be fully isolated behind "mode-setting".
 
-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 usable without the need for an expensive system call over head.
+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).
 
 # Summary of Libre-SOC Commercial Project
 
@@ -96,12 +133,3 @@ 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.
 
-## Why has Libre-SOC chosen PowerPC ?
-
-Our choice was between RISC-V and PowerPC.
-
-The PowerPC architecture is more complete and mature than RISC-V which we initially looked at. 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, eg by putting us in touch with people who can help us.
-
-