(no commit message)

diff --git a/openpower/ISA_WG/Board_letter_26mar2021.mdwn b/openpower/ISA_WG/Board_letter_26mar2021.mdwn
index 837748b25ecfae74ee308fbcbe8bc5c4d0d526cc..6f930e58e67c791b9036e6e82753f4f39877a391 100644 (file)
--- a/openpower/ISA_WG/Board_letter_26mar2021.mdwn
+++ b/openpower/ISA_WG/Board_letter_26mar2021.mdwn
@@ -28,13 +28,16 @@ https://www.sigarch.org/simd-instructions-considered-harmful/
 
 Normally, such huge ISA development efforts would be instigated, organised and funded through either Academia or an extremely large Corporation, or a Consortium combining multiple such entities.  It is therefore without precedent across the Computing Industry for something of this magnitude of effort to come not only from *individuals* with a completely independent non-affiliated Libre background but from a Libre background that is funded by a Charitable Foundation with a mandate to only fund "Works for the Public Good" (NLnet).
 
-From reading the PowerISA v3.0C sections we have learned and taken on board that a "Sandbox" opcode exists (EXT22) which is intended for "small private extensions" to the OpenPOWER ISA.  Our Bitmanipulation Extension alone, needed for Audio/Video and cryptographic workloads, struggles to fit into that space, and we have not yet added Custom 3D opcodes or the IEEE754 Transcendentals (SIN, COS).
+From reading the PowerISA v3.0C sections we have learned and taken on board that a "Sandbox" opcode exists (EXT22) which is intended for "small private extensions" to the OpenPOWER ISA, and the expectation that these extendions mot be supported by upstream toolchains is something we agree wholeheartedly with,
+
+The problem is that our Bitmanipulation Extension alone, needed for Audio/Video and cryptographic workloads, struggles to fit into that space, and we have not yet added Custom 3D opcodes or the IEEE754 Transcendentals (SIN, COS).
 
 http://libre-soc.org/openpower/bitmanip
 
-More than that, these are all "general-purpose" opcodes with uses far beyond LibreSOC's use-case: notwithstanding LibreSOC's use-case itself being by definition general-purpose.  The instructions in the PowerISA v3.0C document therefore *require* us to contact the OpenPOWER Foundation, to initiae the process of including our opcodes, and SVP64, in the OpenPOWER ISA.
+More than that, these are all "general-purpose" opcodes with uses far beyond LibreSOC's use-case (notwithstanding LibreSOC's use-case itself being by definition general-purpose).  More than that, we have a duty and responsibility given that LibreSOC is targetting high-profile mass-volume general-purpose computing, it is our duty to ensure that use of EXT22 does not result in end-user developer pressure for upstream toolchains to override the OPF's intentions, by *unintentionally* de-facto dominating (effectively allocating) EXT22 for LibreSOC use.
 
+The instructions in the PowerISA v3.0C document therefore *require* us to contact the OpenPOWER Foundation, to initiate the process of including our opcodes, and SVP64, in the OpenPOWER ISA.
 
-In speaking with various people (Toshaan, Paul and Hugh) we have pieced together the way that the Op
+In speaking verbally and informally with various people (Toshaan, Paul and Hugh) we have pieced together the way that the OpenPOWER Foundation ISA Workgroup is to be set up.