From: Alain D D Williams Date: Tue, 18 Aug 2020 18:50:25 +0000 (+0100) Subject: Initial version of ISA MUX - a straight convert from the web page. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=fe2c02e0d57f7591a2e27f9dae2ca0fb9cf09e90;p=libresoc-isa-manual.git Initial version of ISA MUX - a straight convert from the web page. Needs more adding words/explanation. --- diff --git a/powerpc-add/src/isamux.tex b/powerpc-add/src/isamux.tex new file mode 100644 index 0000000..670ac87 --- /dev/null +++ b/powerpc-add/src/isamux.tex @@ -0,0 +1,995 @@ +% ISAMUX + +\chapter{Introduction} + +\paragraph{} + +A fixed number of additional (hidden) bits, conceptually a \textbf{namespace}, +set by way of a CSR or other out-of-band mechanism, +that go directly and non-optionally +into the instruction decode phase, extending (in each implementation) the +opcode length to 16+N, 32+N, 48+N, where N is a hard fixed quantity on +a per-implementor basis. + +\paragraph{} + +Where the opcode is normally loaded from the location at the PC, the extra +bits, set via a CSR, are mandatorially appended to every instruction: hence why +they are described as "hidden" opcode bits, and as a \textbf{namespace}. + +\paragraph{} + +The parallels with c++ \textbf{using namespace} are direct and clear. +Alternative conceptual ways to understand this concept include +\textbf{escape-sequencing}. + +\paragraph{} + +TODO: reserve some bits which permit the namespace \textbf{escape-sequence} to +be relevant for a fixed number of instructions at a time. Caveat: +allowing such a countdown to cross branch-points is unwise (illegal +instruction?) + +\paragraph{} + +An example of a pre-existing \textbf{namespace} switch that has been in +prevalent use for several decades (SPARC and other architectures): +dynamic runtime selectability of littel-endian / big-endian \textbf{meaning} +of instructions by way of a \textbf{mode switch} instruction (of some kind). + +\paragraph{} + +That \textbf{switch} is in effect a 33rd (hidden) bit that is part of the opcode, +going directly into the mux / decode phase of instruction decode, and +thus qualifies categorically as a \textbf{namespace}. This proposal both formalises +and generalises that concept. + +\section{Hypothetical Format} \label{hypotheticalformat} + +\paragraph{} + +Note that this is a hypothetical format, yet TBD, where particular attention +needs to be paid to the fact that there is an \textbf{immediate} version of CSRRW +(with 5 bits of immediate) that could save a lot of space in binaries. + +\begin{verbatim} + 3 2 1 +|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +|------------------------------ |-------|---------------------|-| +|1 custom custom custom custom custom | foreignarch |1| +|0 reserved reserved reserved reserved reserved | foreignarch |1| +|custom | reserved | official|B| rvcpage |0| +\end{verbatim} + +\paragraph{} + +RV Mode + +\begin{itemize} +\parskip 0pt +\itemsep 1pt + +\item + +when bit 0 is 0, \textbf{RV} mode is selected. + +\item + +in RV mode, bits 1 thru 5 provide up to 16 possible alternative meanings +(namespaces) for 16 Bit opcodes. \textbf{pages} if you will. The top bit +indicates custom meanings. When set to 0, the top bit is for official usage. + +\item + +Bits 15 thru 23 are reserved. + +\item + +Bits 24 thru 31 are for custom usage. + +\item + +bit 6 (\textbf{B}) is endian-selection: LE/BE + +\end{itemize} + +\paragraph{} + +16 bit page examples: + +\begin{itemize} +\parskip 0pt +\itemsep 1pt + +\item + +0b0000 STANDARD (2019) RVC + +\item + +0b0001 RVCv2 + +\item + +0b0010 RV16 + +\item + +0b0011 RVCv3 + +\item + +... + +\item + +0b1000 custom 16 bit opcode meanings 1 + +\item + +0b1001 custom 16 bit opcode meanings 2 + +\item + +..... + +\end{itemize} + +\paragraph{} + +Foreign Arch Mode + +\begin{itemize} +\parskip 0pt +\itemsep 1pt + +\item + +when bit 0 is 1, \textbf{Foreign arch} mode is selected. + +\item + +Bits 1 thru 7 are a table of foreign arches. + +\item + +when the MSB is 1, this is for custom use. + +\item + +when the MSB is 0, bits 1 thru 6 are reserved for 64 possible official foreign archs. + +\end{itemize} + +\paragraph{} + +Foreign archs could be (examples): + +\begin{itemize} +\parskip 0pt +\itemsep 1pt + +\item + +0b0000000 x86\_32 + +\item + +0b0000001 x86\_64 + +\item + +0b0000010 MIPS32 + +\item + +0b0000011 MIPS64 + +\item + +.... + +\item + +0b0010000 Java Bytecode + +\item + +0b0010001 N.E.Other Bytecode + +\item + +.... + +\item + +0b1000000 custom foreign arch 1 + +\item + +0b1000001 custom foreign arch 2 + +\item + +.... + +\end{itemize} + +\paragraph{} + +Note that \textbf{official} foreign archs have a binary value where the MSB is zero, +and custom foreign archs have a binary value where the MSB is 1. + +\section{Namespaces are permitted to swap to new state} \label{stateswap} + +\paragraph{} + +In each privilege level, on a change of ISANS (whether through manual setting +of ISANS or through trap entry or exit changing the ISANS CSR), an +implementation is permitted to completely and arbitrarily switch not only the +instruction set, it is permitted to switch to a new bank of CSRs (or a subset +of the same), and even to switch to a new PC. + +\paragraph{} + +This to occur immediately and atomically at the point at which the change in ISANS occurs. + +\paragraph{} + +The most obvious application of this is for Foreign Archs, which may have their +own completely separate PC. Thus, foreign assembly code and RISCV assembly code +need not be mixed in the same binary. + +\paragraph{} + +Further use-cases may be envisaged however great care needs to be taken to not +cause massive complications for JIT emulation, as the RV ISANS is unary encoded +(2\^31 permutations). + +\paragraph{} + +In addition, the state information of \textbf{all} namespaces has to be saved +and restored on a context-switch (unless the SP is also switched as part of the +state!) which is quite severely burdensome and getting exceptionally complex. + +\paragraph{} + +Switching CSR, PC (and potentially SP) and other state on a NS change in the +RISCV unary NS therefore needs to be done wisely and responsibly, i.e. +minimised! + +\paragraph{} + +To be discussed. Context +href=https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/x-uFZDXiOxY/27QDW5KvBQAJ + + +\section{Privileged Modes / Traps} \label{privtraps} + +\paragraph{} + +An additional WLRL CSR per priv-level named \textbf{LAST-ISANS} is required, and +another called \textbf{TRAP-ISANS} +These mirrors the ISANS CSR, and, on a trap, the current ISANS in +that privilege level is atomically +transferred into LAST-ISANS by the hardware, and ISANS in that trap +is set to TRAP-ISANS. Hardware is \textbf{only then} permitted to modify the PC to +begin execution of the trap. + +\paragraph{} + +On exit from the trap, LAST-ISANS is copied into the ISANS CSR, and +LAST-ISANS is set to TRAP-ISANS. \textbf{Only then} is the hardware permitted +to modify the PC to begin execution where the trap left off. + +\paragraph{} + +This is identical to how xepc is handled. + +\paragraph{} + +Note 1: in the case of Supervisor Mode (context switches in particular), +saving and changing of LAST-ISANS (to and from the stack) must be done +atomically and under the protection of the SIE bit. Failure to do so +could result in corruption of LAST-ISANS when multiple traps occur in +the same privilege level. + +\paragraph{} + +Note 2: question - should the trap due to illegal (unsupported) values +written into LAST-ISANS occur when the \textbf{software} writes to LAST-ISANS, +or when the \textbf{trap} (on exit) writes into LAST-ISANS? this latter seems +fraught: a trap, on exit, causing another trap?? + +\paragraph{} + +Per-privilege-level pseudocode (there exists UISANS, UTRAPISANS, ULASTISANS, +MISANS, MTRAPISANS, MLASTISANS and so on): + +\begin{verbatim} +trap_entry() +{ + LAST-ISANS = ISANS // record the old NS + ISANS = TRAP_ISANS // traps are executed in "trap" NS +} + +and trap_exit: + +trap_exit(): +{ + ISANS = LAST-ISANS + LAST-ISANS = TRAP_ISANS +} +\end{verbatim} + +\section{Alternative RVC 16 Bit Opcode meanings} \label{alternativervc16bitopcodemeanings} + +\paragraph{} + +Here is appropriate to raise an idea how to cover RVC and future +variants, including RV16. + +\paragraph{} + +Just as with foreign archs, and you quite rightly highlight above, it +makes absolutely no sense to try to select both RVCv1, v2, v3 and so on, +all simultaneously. An unary bit vector for RVC modes, changing the 16 +BIT opcode space meaning, is wasteful and again has us believe that WARL +is the \textbf{solution}. + +\paragraph{} + +The correct thing to do is, again, just like with foreign archs, to +treat RVCs as a \textbf{binary} namespace selector. Bits 1 thru 3 would give +8 possible completely new alternative meanings, just like how the Z80 +and the 286 and 386 used to do bank switching. + +\paragraph{} + +All zeros is clearly reserved for the present RVC. 0b001 for RVCv2. 0b010 +for RV16 (look it up) and there should definitely be room reserved here +for custom reencodings of the 16 bit opcode space. + +\section{FAQ}\label{faq} + +\subsection{Why not have TRAP-ISANS as a vector table, matching mtvec?} \label{trap-isans-vec} + +\paragraph{} + +Use case to be determined. Rather than be a global per-priv-level value, +TRAP-ISANS is a table of length exactly equal to the mtvec/utvec/stvec table, +with corresponding entries that specify the assembly-code namespace in which +the trap handler routine is written. + +\paragraph{} + +Open question: see https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/IAhyOqEZoWA/BM0G3J2zBgAJ + +\begin{verbatim} +trap_entry(x_cause) +{ + LAST-ISANS = ISANS // record the old NS + ISANS = TRAP_ISANS_VEC[xcause] // traps are executed in "trap" NS +} + +and trap_exit: + +trap_exit(x_cause): +{ + ISANS = LAST-ISANS + LAST-ISANS = TRAP_ISANS_VEC[x_cause] +} +\end{verbatim} + +\subsection{Is this like MISA?} \label{misa} + +\paragraph{} + +No. + +\begin{itemize} +\parskip 0pt +\itemsep 1pt + +\item + +MISA's space is entirely taken up (and running out). + +\item + +There is no allocation (provision) for custom extensions. + +\item + +MISA switches on and off entire extensions: ISAMUX/NS may be used to switch +multiple opcodes (present and future), to alternate meanings. + +\item + +MISA is WARL and is inaccessible from everything but M-Mode (not even readable). + +\end{itemize} + +\paragraph{} + +MISA is therefore wholly unsuited to U-Mode usage; ISANS is specifically +permitted to be called by userspace to switch (with no stalling) between +namespaces, repeatedly and in quick succession. + +\subsection{What happens if this scheme is not adopted? Why is it better than leaving things well alone?} \label{laissezfaire} + +\paragraph{} + +At the first sign of an emergency non-backwards compatible and unavoidable +change to the \textbf{frozen} RISCV \textbf{official} Standards, the entire RISCV +community is fragmented and divided into two: + +\begin{itemize} +\parskip 0pt +\itemsep 1pt + +\item + +Those vendors that are hardware compatible with the legacy standard. + +\item + +Those that are compatible with the new standard. + +\end{itemize} + +\paragraph{} + +\textbf{These two communities would be mutually exclusively incompatible}. If +a second emergency occurs, RISCV becomes even less tenable. + +\paragraph{} + +Hardware that wished to be \textbf{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. + +\paragraph{} + +By providing a \textbf{safety valve} in the form of a hidden namespace, at least +newer hardware has the option to implement both (or more) variations, +\textbf{and still apply for Certification}. + +\paragraph{} + +However to also allow \textbf{legacy} hardware to at least be JIT soft +compatible, some very strict rules \textbf{must} be adhered to, that appear at +first sight not to make any sense. + +\paragraph{} + +It's complicated in other words! + +\subsection{Surely it's okay to just tell people to use 48-bit encodings?} \label{use48bit} + +\paragraph{} + +Short answer: it doesn't help resolve conflicts, and costs hardware and +redesigns to do so. Softcores in cost-sensitive embedded applications may +even not actually be able to fit the required 48 bit instruction decode engine +into a (small, ICE40) FPGA. 48-bit instruction decoding is much more complex +than straight 32-bit decoding, requiring a queue. + +\paragraph{} + +Second answer: conflicts can still occur in the (unregulated, custom) 48-bit +space, which \textbf{could} be resolved by ISAMUX/ISANS as applied to the \textbf{48} bit +space in exactly the same way. And the 64-bit space. + +\subsection{Why not leave this to individual custom vendors to solve on a case by case basis?} \label{case-by-case} + +\paragraph{} + +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. + +\paragraph{} + +The problems with this approach are numerous, when presented to a +worldwide context that the UNIX Platform, in particular, has to face +(where the embedded platform does not) + +\paragraph{} + +First: lack of coordination, in the proliferation of arbitrary solutions, +has to primarily be borne by gcc, binutils, LLVM and other compilers. + +\paragraph{} + +Secondly: CSR space is precious. With each vendor likely needing only one +or two bits to express the namespace collision avoidance, if they make +even a token effort to use worldwide unique CSRs (an effort that would +benefit compiler writers), the CSR register space is quickly exhausted. + +\paragraph{} + +Thirdly: JIT Emulation of such an unregulated space becomes just as +much hell as it is for compiler writers. In addition, if two vendors +use conflicting CSR addresses, the only sane way to tell the emulator +what to do is to give the emulator a runtime commandline argument. + +\paragraph{} + +Fourthly: with each vendor coming up with their own way of handling +conflicts, not only are the chances of mistakes higher, it is against the +very principles of collaboration and cooperation that save vendors money +on development and ongoing maintenance. Each custom vendor will have +to maintain their own separate hard fork of the toolchain and software, +which is well known to result in security vulnerabilities. + +\paragraph{} + +By coordinating and managing the allocation of namespace bits (unary +or binary) the above issues are solved. CSR space is no longer wasted, +compiler and JIT software writers have an easier time, clashes are +avoided, and RISCV is stabilised and has a trustable long term future. + +\subsection{ Why ISAMUX / ISANS has to be WLRL and mandatory trap on illegal writes} \label{wlrlmandatorytrap} + +\paragraph{} + +The namespaces, set by bits in the CSR, are functionally directly +equivalent to c++ namespaces, even down to the use of braces. + +\paragraph{} + +WARL, by allowing implementors to choose the value, prevents and prohibits +the critical and necessary raising of an exception that would begin the +JIT process in the case of ongoing standards evolution. + +\paragraph{} + +Without this opportunity, an implementation has no reliable guaranteed way of knowing +when to drop into full JIT mode, +which is the only guaranteed way to distinguish +any given conflicting opcode. It is as if the c++ +standard was given a similar optional +opportunity to completely ignore the +\textbf{using namespace} prefix! + +\paragraph{} + +-- + +\paragraph{} + +Ok so I trust it's now clear why WLRL (thanks Allen) is needed. + +\paragraph{} + +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. + +\paragraph{} + +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. + +\paragraph{} + +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. + +\paragraph{} + +This \textbf{IS} on the face of it a legitimate reason to make ISAMUX/ISANS WARL. + +\paragraph{} + +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: + +\paragraph{} + +x86 and simultaneous RVCv2 modes are total nonsense in the first place! + +\paragraph{} + +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 \textbf{only}, and if 1, the ISAMUX/ISANS is a \textbf{binary} +table of foreign architectures and foreign architectures only. + +\paragraph{} + +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 \textbf{official} foreign instruction sets to +be hardware-supported/JIT-emulated seems to be sufficiently gratuitous, +to me. + +\paragraph{} + +One of those could even be Java Bytecode! + +\paragraph{} + +Now, it could \textbf{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. + +\paragraph{} + +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). + +\paragraph{} + +So, thank you, again, Dan, for raising this. It would have completely +jeapordised ISAMUX/NS if not spotted. + +\paragraph{} + +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 \textbf{more} future namespaces, +through JIT emulation, if this is not planned properly in advance? + +\paragraph{} + +Let us take the simple case first: a current 2019 RISCV fully compliant +RV64GC UNIX capable system (with mandatory traps on all unsupported CSRs). + +\paragraph{} + +Fast forward 20 years, there are now 5 ISAMUX/NS unary bits, and 3 +foreign arch binary table entries. + +\paragraph{} + +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. + +\paragraph{} + +(This again emphasises exactly why the trap is mandatory). + +\paragraph{} + +Now let us take the case of a hypothetical system from say 2021 that +implements RVCv2 at the hardware level. + +\paragraph{} + +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 \textbf{illegal} bits was acceptable, making the +transition to JIT mode flat-out impossible to detect. + +\paragraph{} + +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 \textbf{full} set of bits in the ISAMUX/NS CSR \textbf{in advance}. + +\paragraph{} + +i.e. that \textbf{right now}, in the year 2019, the entire ISAMUX/NS CSR cannot +be added to piecemeal, the full 32 (or 64) bits \textbf{has} to be reserved, +and reserved bits set at zero. + +\paragraph{} + +Furthermore, if any software attempts to write to those reserved bits, +it \textbf{must} be treated just as if those bits were distinct and nonexistent +CSRs, and a trap raised. + +\paragraph{} + +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). + +\paragraph{} + +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). + +\paragraph{} + +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. + +\paragraph{} + +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. + +\paragraph{} + +Lastly, I \textbf{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. + +\paragraph{} + +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. + +\subsection{Why WARL will not work and why WLRL is required} + +\paragraph{} + +WARL requires a follow-up read of the CSR to ascertain what heuristic +the hardware \textbf{might} have applied, and if that procedure is followed in +this proposal, performance even on hardware would be severely compromised. + +\paragraph{} + +In addition when switching to foreign architectures, the switch has to +be done atomically and guaranteed to occur. + +\paragraph{} + +In the case of JIT emulation, the WARL \textbf{detection} code will be in an +assembly language that is alien to hardware. + +\paragraph{} + +Support for both assembly languages immediately after the CSR write +is clearly impossible, this leaves no other option but to have the CSR +be WLRL (on all platforms) and for traps to be mandatory (on the UNIX +Platform). + +\subsection{Is it strictly necessary for foreign archs to switch back?} \label{foreignswitch} + +\paragraph{} + +No, because LAST-ISANS handles the setting and unsetting of the ISANS CSR +in a completely transparent fashion as far as the foreign arch is concerned. +Supervisor or Hypervisor traps take care of the context switch in a way +that the user mode (or guest) need not be aware of, in any way. + +\paragraph{} + +Thus, in e.g. Hypervisor Mode, the foreign guest arch has no knowledge +or need to know that the hypervisor is flipping back to RV at the time of +a trap. + +\paragraph{} + +Note however that this is \textbf{not} the same as the foreign arch executing +\textbf{foreign} traps! Foreign architecture trap and interrupt handling mechanisms +are \textbf{out of scope} of this document and MUST be handled by the foreign +architecture implementation in a completely transparent fashion that in +no way interacts or interferes with this proposal. + +\subsection{Can we have dynamic declaration and runtime declaration of capabilities?} \label{dynamic} + +\paragraph{} + +Answer: don't know (yet). Quoted from Rogier: + +\begin{quote} +"A SOC may have several devices that one may want to directly control +with custom instructions. If independent vendors use the same opcodes you +either have to change the encodings for every different chip (not very +nice for software) or you can give the device an ID which is defined in +some device tree or something like that and use that." +\end{quote} + +\paragraph{} + +dynamic detection wasn't originally planned: static +compilation was envisaged to solve the need, with a table of +mvendorid-marchid-isamux/isans being maintained inside gcc / binutils / +llvm (or separate library?) that, like the linux kernel ARCH table, +requires a world-wide atomic \textbf{git commit} to add globally-unique +registered entries that map functionality to actual namespaces. + +\paragraph{} + +where that goes wrong is if there is ever a pair (or more) of vendors +that use the exact same custom feature that maps to different opcodes, +a statically-compiled binary has no hope of executing natively on both +systems. + +\paragraph{} + +at that point: yes, something akin to device-tree would be needed. + +\section{Open Questions}\label{open-questions} + +\paragraph{} + +This section from a post by Rogier Bruisse +\href{http://hands.com/~lkcl/gmail_re_isadev_isamux.html}{http://hands.com/~lkcl/gmail\_re\_isadev\_isamux.html} + +\subsection{is the ISANS CSR a 32 or XLEN bit value?} \label{isans-32-or-xlen} + +\paragraph{} + +This is partly answered in another FAQ above: if 32 bits is not enough +for a full suite of official, custom-with-atomic-registration and custom-without +then a second CSR group (ISANS2) may be added at a future date (10-20 years +hence). + +\paragraph{} + +32 bits would not inconvenience RV32, and implementors wishing to +make significant altnernative modifications to opcodes in the RV32 ISA space +could do so without the burden of having to support a split 32/LO 32/HI +CSR across two locations. + +\subsection{Is the ISANS a flat number space or should some bits be reserved for use as flags?} + +\paragraph{} + +See 16-bit RV namespace "page" concept, above. Some bits have to be unary +(multiple simultaneous features such as LE/BE in one bit, and augmented +Floating-point rounding / clipping in another), whilst others definitely +need to be binary (the most obvious one being \textbf{paging} in the space currently +occupied by RVC). + +\subsection{Should the ISANS space be partitioned between reserved, custom with registration guaranteed non clashing, custom, very likely non clashing?} + +\paragraph{} + +Yes. Format TBD. + +\subsection{Should only compiler visible/generated constant setting with CSRRWI and/or using a clearly recognisable LI/LUI be accommodated or should dynamic setting be accommodated as well?} + +\paragraph{} + +This is almost certainly a software design issue, not so much a hardware +issue. + +\subsection{How should the ISANS be (re)stored in a trap and in context switch?} + +\paragraph{} + +See section above on privilege mode: LAST-ISANS has been introduced that +mirrors (x)CAUSE and (x)EPC pretty much exactly. Context switches change +uepc just before exit from the trap, in order to change the user-mode PC +to switch to a new process, and ulast-isans can - must - be treated in +exactly the same way. When the context switch sets ulast-isans (and uepc), +the hardware flips both ulast-isans into uisans and uepc into pc (atomically): +both the new NS and the new PC activate immediately, on return to usermode. + +\paragraph{} + +Quite simple. + +\subsection{Should the mechanism accommodate "foreign ISA's" and if so how does one restore the ISA.} + +\paragraph{} + +See section above on LAST-ISANS. With the introduction of LAST-ISANS, the +change is entirely transparent, and handled by the Supervisor (or Hypervisor) +trap, in a fashion that the foreign ISA need not even know of the existence +of ISANS. At all. + +\subsection{Where is the default ISA stored and what is responsible for what it is after} + +\paragraph{} + +Options: +\begin{itemize} +\parskip 0pt +\itemsep 1pt + +\item + +start up + +\item + +starting a program + +\item + +calling into a dynamically linked library + +\item + +taking a trap + +\item + +changing privilege levels + +\end{itemize} + +\paragraph{} + +These first four are entirely at the discretion of (and the +responsibility of) the software. There is precedent for most of these +having been implemented, historically, at some point, in relation to +LE/BE mode CSRs in other hardware (MIPSEL vs MIPS distros for example). + +\paragraph{} + +Traps are responsible for saving LAST-ISANS on the stack, exactly as they +are also responsible for saving other context-sensitive information such +as the registers and xEPC. + +\paragraph{} + +The hardware is responsible for atomically switching out ISANS into the +relevant xLAST-ISANS (and back again on exit). See Privileged Traps, +above. + +\subsection{If the ISANS is just bits of an instruction that are to be prefixed by the cpu, can those bits contain immediates? Register numbers?} + +\paragraph{} + +The concept of a CSR containing an immediate makes no sense. The concept +of a CSR containing a register number, the contents of which would, presumably, +be inserted into the NS, would immediately make that register a permanent +and irrevocably reserved register that could not be utilised for any other +purpose. + +\paragraph{} + +This is what the CSRs are supposed to be for! + +\paragraph{} + +It would be better just to have a second CSR - ISANS2 - potentially even ISANS3 +in 60+ years time, rather than try to use a GPR for the purposes for which CSRs +are intended. + +\subsection{How does the system indicate a namespace is not recognised? Does it trap or can/must a recoverable mechanism be provided?} + +\paragraph{} + +It doesn't "indicate" that a namespace is not recognised. WLRL fields only +hold supported values. If the hardware cannot hold the value, a trap +\textbf{MUST} be thrown (in the UNIX platform), and at that point it becomes the +responsibility of software to deal with it. + +\subsection{What are the security implications? Can some ISA namespaces be set by user space?} + +\paragraph{} + +Of course they can. It becomes the responsibility of the Supervisor Mode +(the kernel) to treat ISANS in a fashion orthogonal to the PC. If the OS +is not capable of properly context-switching securely by setting the right +PC, it's not going to be capable of properly looking after changes to ISANS. + +\subsection{Does the validity of an ISA namespace depend on privilege level? If so how?} + +\paragraph{} + +The question does not exactly make sense, and may need a re-reading of the +section on how Privilege Modes, above. In RISC-V, privilege modes do not +actually change very much state of the system: the absolute minimum changes +are made (swapped out) - xEPC, xSTATUS and so on - and the privilege mode +is expected to handle the context switching (or other actions) itself. + +\paragraph{} + +ISANS - through LAST-ISANS - is absolutely no different. The trap and the +kernel (Supervisor or Hypervisor) are provided the \textbf{mechanism} by which +ISA Namespace \textbf{may} be set: it is up to the software to use that mechanism +correctly, just as the software is expected to use the mechanisms provided +to correctly implement context-switching by saving and restoring register +files, the PC, and other state. The NS effectively becomes just another +part of that state.