From 380e634722af141b524f91966c410e829af16ed3 Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 13 Jun 2019 06:47:48 +0100 Subject: [PATCH] --- isa_conflict_resolution/isamux_isans.mdwn | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/isa_conflict_resolution/isamux_isans.mdwn b/isa_conflict_resolution/isamux_isans.mdwn index 364bbd654..205278caf 100644 --- a/isa_conflict_resolution/isamux_isans.mdwn +++ b/isa_conflict_resolution/isamux_isans.mdwn @@ -69,7 +69,7 @@ the same trap vectors, many would not. or, at least, the very first thing that each would do is: push the current ISAMUX/ISANS value onto the stack, set it to a "known-good" -value, and call the "common" trap vector as a function. when that +value (almost certainly the current 2019 Base Standard RV but not necessarily required to be so), and call the "common" trap vector as a function. when that function exits, the ISAMUX/ISANS is popped off the stack, returned to its former value, and the trap allowed to exit. @@ -80,6 +80,23 @@ going to work. thus, the need for having a per-privilege per-permutation utvec/stvec/htvec. +# What happens if this scheme is not adopted? Why is it better than leaving things well alone? + +At the first sign of an emergency non-backwards compatible and unavoidable change to the *frozen* RISCV *official* Standards, the entire RISCV community is fragmented and divided into two: + +* Those vendors that are hardware compatible with the legacy standard. +* Those that are compatible with the new standard. + +*These two communities would be mutually exclusively incompatible*. If a second emergency occurs, RISCV becomes even less tenable. + +Hardware that wished to be "compatible" with either flavour would require JIT or offline static binary recompilation. No vendor would willingly accept this as a condition of the standards divergence in the first place, locking up decision making to the detriment of RISCV as a whole. + +By providing a "safety valve" in the form of a hidden namespace, at least newer hardware has the option to implement both (or more) variations, *and still apply for Certification*. + +However to also allow "legacy" hardware to at least be JIT soft compatible, some very strict rules *must* be adhered to, that appear at first sight not to make amy sense. + +It's complicated in other words! + # Why not leave this to individual custom vendors to solve on a case by case basis? The suggestion was raised that a custom extension vendor could create their own CSR that selects between conflicting namespaces that resolve the meaning of the exact same opcode. This to be done by all and any vendors, as they see fit, with little to no collaboration or coordination towards standardisation in any form. -- 2.30.2