(no commit message)

diff --git a/openpower/ISA_WG/Board_letter_26mar2021.mdwn b/openpower/ISA_WG/Board_letter_26mar2021.mdwn
index b6f4519bccddb860a180eaad6524dd3493387d94..de7369ac6a77a1c027fb2f39884940c144eb43d0 100644 (file)
--- a/openpower/ISA_WG/Board_letter_26mar2021.mdwn
+++ b/openpower/ISA_WG/Board_letter_26mar2021.mdwn
@@ -7,6 +7,7 @@ edit history:
 
 * 25mar2021 first revision
 * fix typos
+* grammar fix
 
 to be sent to:
 
@@ -30,7 +31,7 @@ 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, and the expectation that these extensions not be supported by upstream tool-chains is something we agree wholeheartedly with,
+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.  The expectation that these extensions not be supported by upstream tool-chains is something with which we wholeheartedly agree.
 
 The problem is that our Bit-Manipulation 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).