thus, the need for having a per-privilege per-permutation utvec/stvec/htvec.
+# Why ISAMUX / ISANS has to be WLRL and mandatory trap on illegal writes
+
+Ok so I trust it's now clear why WLRL (thanks Allen) is needed.
+
+When Dan raised the WARL concern initially a situation was masked by the conflict, that if gone unnoticed would jeapordise ISAMUX/ISANS entirely. Actually, two separate errors. So thank you for raising the question.
+
+The situation arises when foreign archs are to be given their own NS bit. MIPS is allocated bit 8, x86 bit 9, whilst LE/BE is given bit 0, RVCv2 bit 1 andso on. All of this potential rather than actual, clearly.
+
+Imagine then that software tries to write and set not just bit 8 and bit 9, it also tries to set bit 0 and 1 as well.
+
+This *IS* on the face of it a legitimate reason to make ISAMUX/ISANS WARL.
+
+However it masks a fundamental flaw that has to be addressed, which brings us back much closer to the original design of 18 months ago, and it's highlighted thus:
+
+x86 and simultaneous RVCv2 modes are total nonsense in the first place!
+
+The solution instead is to have a NS bit (bit0) that SPECIFICALLY determines if the arch is RV or not. If 0, the rest of the ISAMUX/ISANS is very specifically RV *only*, and if 1, the ISAMUX/ISANS is a *binary* table of foreign architectures and foreign architectures only.
+
+Exactly how many bits are used for the foreign arch table, is to be determined. 7 bits, one of which is reserved for custom usage, leaving a whopping 64 possible "official" foreign instruction sets to be hardware-supported/JIT-emulated seems to be sufficiently gratuitous, to me.
+
+One of those could even be Java Bytecode!
+
+Now, it could *hypothetically* be argued that the permutation of setting LE/BE and MIPS for example is desirable. A simple analysis shows this not to be the case: once in the MIPS foreign NS, it is the MIPS hardware implementation that should have its own way of setting and managing its LE/BE mode, because to do otherwise drastically interferes with MIPS binary compatibility.
+
+Thus, it is officially Not Our Problem: only flipping into one foreign arch at a time makes sense, thus this has to be reflected in the ISAMUX/ISANS CSR itself, completely side-stepping the (apparent) need to make the NS CSR WARL (which would not work anyway, as previously mentioned).
+
+So, thank you, again, Dan, for raising this. It would have completely jeapordised ISAMUX/NS if not spotted.
+
+The second issue is: how does any hardware system, whether it support ISANS or not, and whether any future hardware supports some Namespaces and, in a transitive fashion, has to support *more* future namespaces, through JIT emulation, if this is not planned properly in advance?
+
+Let us take the simple case first: a current 2019 RISCV fully compliant RV64GC UNIX capable system (with mandatory traps on all unsupported CSRs).
+
+Fast forward 20 years, there are now 5 ISAMUX/NS unary bits, and 3 foreign arch binary table entries.
+
+Such a system is perfectly possible of software JIT emulating ALL of these options because the write to the (illegal, for that system) ISAMUX/NS CSR generates the trap that is needed for that system ti begin JIT mode.
+
+(This again emphasises exactly why the trap is mandatory).
+
+Now let us take the case of a hypothetical system from say 2021 that implements RVCv2 at the hardware level.
+
+Fast forward 20 years: if the CSR were made WARL, that system would be absolutely screwed. The implementor would be under the false impression that ignoring setting of "illegal" bits was acceptable, making the transition to JIT mode flat-out impossible to detect.
+
+When this is considered transitively, considering all future additions to the NS, and all permutations, it can be logically deduced that there is a need to reserve a *full* set of bits in the ISAMUX/NS CSR *in advance*.
+
+i.e. that *right now*, in the year 2019, the entire ISAMUX/NS CSR cannot be added to piecemeal, the full 32 (or 64) bits *has* to be reserved, and reserved bits set at zero.
+
+Furthermore, if any software attempts to write to those reserved bits, it *must* be treated just as if those bits were distinct and nonexistent CSRs, and a trap raised.
+
+It makes more sense to consider each NS as having its own completely separate CSR, which, if it does not exist, clearly it should be obvious that, as an unsupported CSR, a trap should be raised (and JIT emulation activated).
+
+However given that only the one bit is needed (in RV NS Mode, not Foreign NS Mode), it would be terribly wasteful of the CSRs to do this, despite it being technically correct and much easier to understand why trap raising is so essential (mandatory).
+
+This again should emphasise how to mentally get one's head round this mind-bendingly complex problem space: think of each NS bit as its own totally separate CSR that every implementor is free and clear to implement (or leave to JIT Emulation) as they see fit.
+
+Only then does the mandatory need to trap on write really start to hit home, as does the need to preallocate a full set of reserved zero values in the RV ISAMUX/NS.
+
+Lastly, I *think* it's ok to only reserve say 32 bits, and, in 50 years time if that genuinely is not enough, start the process all over again with a new CSR. ISAMUX2/NS2.
+
+Subdivision of the RV NS (support for RVCv3/4/5/RV16 without wasting precious CSR bits) best left for discussion another time, the above is a heck of a lot to absorb, already.
projects / libreriscv.git / commitdiff