From c3405296f9988000e54ebb6d8e2b815362f131d7 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 26 Mar 2021 17:49:11 +0000 Subject: [PATCH] --- openpower/ISA_WG/Board_letter_26mar2021.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openpower/ISA_WG/Board_letter_26mar2021.mdwn b/openpower/ISA_WG/Board_letter_26mar2021.mdwn index d3975150b..781db7f26 100644 --- a/openpower/ISA_WG/Board_letter_26mar2021.mdwn +++ b/openpower/ISA_WG/Board_letter_26mar2021.mdwn @@ -44,9 +44,9 @@ More than that, these are all "general-purpose" opcodes with uses far beyond Lib More than that, going far beyond the "letter" of our obligations to respect the stability of the OpenPOWER ecosystem, given that LibreSOC is targeting high-profile mass-volume general-purpose computing, it is our duty and responsibility to ensure that use of EXT22 does not result in end-user developer pressure for upstream tool-chains to override the OPF's remit, by *unintentionally* de-facto dominating EXT22 for LibreSOC use simply by popular overwhelming end-user demand, outside of everyone's control. -We are also getting slightly concerned in that the resources needed (SPR allocations, allocation of Reserved v3.1 64 bit EXT01 prefix space to support SVP64) is quite large, and well outside of the "anticipated" resources allocated for Sandboxing, yet after one year we still have no two-way communications channel established to discuss the possibility of additional reservations. +We are also getting slightly concerned in that the resources needed (SPR allocations, allocation of Reserved v3.1 64 bit EXT01 prefix space to support SVP64) is quite large, and well outside of the "anticipated" resources allocated for Sandboxing. There is no allocation of EXT01 *at all* for example. Yet after one year we still have no two-way communications channel established to discuss even the possibility of additional reservations. -The advice 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. +The advice in the PowerISA v3.0C document *requires* us to contact the OpenPOWER Foundation, to initiate the process of including our opcodes, and SVP64, in the OpenPOWER ISA, yet, here, we run into an interesting twist. 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, and we have become aware that there may be a mis-match here caused by "otherwise normally expected" provenance of ISA proposals which, from what we can gather, is being built-in to the ISA WG's by-laws. -- 2.30.2