clarification
authorLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Tue, 31 Dec 2019 05:54:31 +0000 (05:54 +0000)
committerLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Tue, 31 Dec 2019 05:54:31 +0000 (05:54 +0000)
updates/021_2019dec29_nlnet_grants_approved.mdwn

index e11ea6cbe3251afd5d0e613e42085bc7731a3097..c9620ff714be72441b91817ff66e2fbd151755da 100644 (file)
@@ -169,13 +169,13 @@ with a *userspace* RV64GC dual-ISA front-end.  **Userspace** RISC-V POSIX
 PowerISA POSIX applications, however the **kernel** (supervisor) space will
 be entirely PowerISA.
 
-The video and 3D acceleration opcodes will be **entirely in the Power ISA**.
-We are sick and tired of the RISC-V Foundation's blatant mismanagement.
-Therefore, we will comply to the absolute minimal letter with RV64GC for
-the benefit of our users, backers, and sponsors. However, RISC-V and the
-RISC-V ISA itself
-will no longer receive the benefit of the advancements and innovation
-that we have received funding and support to develop.
+The video and 3D acceleration opcodes will be **entirely in the Power
+ISA**.  We are sick and tired of the RISC-V Foundation's intransigence
+and blatant mismanagement.  Therefore, we will comply to the absolute
+minimal letter with RV64GC for the benefit of our users, backers, and
+sponsors who will be expecting RISC-V Compliance.  However, RISC-V and the
+RISC-V ISA itself will no longer receive the benefit of the advancements
+and innovation that we have received funding and support to develop.
 
 So, the assembly-code being written by hand for the video acceleration
 side, as well as the 3D drivers for Kazan and MESA, will "flip" from RV64GC