# Note-form on ISAMUX (aka "ISANS")
-A fixed number of additional (hidden) bits, conceptually a "namespace", that go directly and non-optionally
+Links:
+
+* <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-February/004190.html>
+* bugreport <http://bugs.libre-riscv.org/show_bug.cgi?id=214>
+
+A fixed number of additional (hidden) bits, conceptually a "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.
Where the opcode is normally loaded from the location at the PC, the extra
-bits are instead set via a CSR and mandatorially appended to every instruction: hence why they are described as "hidden" opcode bits, and as a "namespace".
+bits, set via a CSR, are mandatorially appended to every instruction: hence why they are described as "hidden" opcode bits, and as a "namespace".
The parallels with c++ "using namespace" are direct and clear.
+Alternative conceptual ways to understand this concept include
+"escape-sequencing".
+
+TODO: reserve some bits which permit the namespace (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?)
+
+An example of a pre-existing "namespace" switch that has been in
+prevalent use for several decades (SPARC and other architectures):
+dynamic runtime selectability of littel-endian / big-endian "meaning"
+of instructions by way of a "mode switch" instruction (of some kind).
+
+That "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 "namespace". This proposal both formalises
+and generalises that concept.
# Hypothetical Format
needs to be paid to the fact that there is an "immediate" version of CSRRW
(with 5 bits of immediate) that could save a lot of space in binaries.
-<code>
<pre>
- 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|
- |------------------------------ |-------|---------------------|-|
- |reserved reserved reserved reserved reserved | foreignarch |1|
- |custom | reserved | official|B| rvcpage |0|
+ 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|
</pre>
-<code>
RV Mode
* in RV mode, bits 1 thru 5 provide up to 16 possible alternative meanings (namespaces) for 16 Bit opcodes. "pages" if you will. The top bit indicates custom meanings. When set to 0, the top bit is for official usage.
* Bits 15 thru 23 are reserved.
* Bits 24 thru 31 are for custom usage.
-* bit 6 ("B") is LE/BE
+* bit 6 ("B") is endian-selection: LE/BE
16 bit page examples:
Note that "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.
-# Privileged Modes / Traps <a href="#privtraps" />
+# Namespaces are permitted to swap to new state <a name="stateswap"></a>
+
+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.
+
+This to occur immediately and atomically at the point at which the change in ISANS occurs.
+
+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.
+
+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).
+
+In addition, the state information of *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.
+
+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!
+
+To be discussed. Context <https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/x-uFZDXiOxY/27QDW5KvBQAJ>
+
+# Privileged Modes / Traps <a name="privtraps"></a>
+
+An additional WLRL CSR per priv-level named "LAST-ISANS" is required, and
+another called "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 *only then* permitted to modify the PC to
+begin execution of the trap.
-An additional WLRL CSR per priv-level named "LAST-ISANS" is required.
-This mirrors the ISANS CSR, and, on a trap, if the current ISANS in
-that privilegel level is non-zero, its value is atomically transferred
-into LAST-ISANS by the hardware, and ISANS in that trap is set to zero.
-Hardware is *only then* permitted to modify the PC to begin execution
-of the trap.
+On exit from the trap, LAST-ISANS is copied into the ISANS CSR, and
+LAST-ISANS is set to TRAP-ISANS. *Only then* is the hardware permitted
+to modify the PC to begin execution where the trap left off.
-On exit from the trap, hardware must check to see if LAST-ISANS is non-zero.
-If it is non-zero, its value is copied into the ISANS, LAST-ISANS is set to
-zero, and *only then* is the hardware permitted to modify the PC to begin
-execution where the trap left off.
+This is identical to how xepc is handled.
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
or when the *trap* (on exit) writes into LAST-ISANS? this latter seems
fraught: a trap, on exit, causing another trap??
-# What happens if this scheme is not adopted? Why is it better than leaving things well alone? <a href="#lassezfaire">
+Per-privilege-level pseudocode (there exists UISANS, UTRAPISANS, ULASTISANS,
+MISANS, MTRAPISANS, MLASTISANS and so on):
+
+<pre>
+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
+}
+</pre>
+
+# Alternative RVC 16 Bit Opcode meanings
+
+Here is appropriate to raise an idea how to cover RVC and future
+variants, including RV16.
+
+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 "solution".
+
+The correct thing to do is, again, just like with foreign archs, to
+treat RVCs as a *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.
+
+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.
+
+# FAQ
+
+## Why not have TRAP-ISANS as a vector table, matching mtvec? <a name="trap-isans-vec"></a>
+
+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.
+
+Open question: see <https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/IAhyOqEZoWA/BM0G3J2zBgAJ>
+
+<pre>
+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]
+}
+</pre>
+
+## Is this like MISA? <a name="misa"></a>
+
+No.
+
+* MISA's space is entirely taken up (and running out).
+* There is no allocation (provision) for custom extensions.
+* MISA switches on and off entire extensions: ISAMUX/NS may be used to switch multiple opcodes (present and future), to alternate meanings.
+* MISA is WARL and is inaccessible from everything but M-Mode (not even readable).
+
+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.
+
+## What happens if this scheme is not adopted? Why is it better than leaving things well alone? <a name="laissezfaire"></a>
At the first sign of an emergency non-backwards compatible and unavoidable
change to the *frozen* RISCV *official* Standards, the entire RISCV
It's complicated in other words!
-# Why not leave this to individual custom vendors to solve on a case by case basis?
+## Surely it's okay to just tell people to use 48-bit encodings? <a name="use48bit"></a>
+
+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.
+
+Second answer: conflicts can still occur in the (unregulated, custom) 48-bit
+space, which *could* be resolved by ISAMUX/ISANS as applied to the *48* bit
+space in exactly the same way. And the 64-bit space.
+
+## Why not leave this to individual custom vendors to solve on a case by case basis? <a name="case-by-case"></a>
The suggestion was raised that a custom extension vendor could create
their own CSR that selects between conflicting namespaces that resolve
compiler and JIT software writers have an easier time, clashes are
avoided, and RISCV is stabilised and has a trustable long term future.
-# Why ISAMUX / ISANS has to be WLRL and mandatory trap on illegal writes
+## Why ISAMUX / ISANS has to be WLRL and mandatory trap on illegal writes <a name="wlrlmandatorytrap"></a>
The namespaces, set by bits in the CSR, are functionally directly
equivalent to c++ namespaces, even down to the use of braces.
the critical and necessary raising of an exception that would begin the
JIT process in the case of ongoing standards evolution.
-Without this opportunity, an implementation has no way of knowing
-how to JIT emulate any given conflicting opcode. It is as if the c++
-standard was given the similar opportunity to completely ignore the
+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
"using namespace" prefix!
--
precious CSR bits) best left for discussion another time, the above is
a heck of a lot to absorb, already.
-# Alternative RVC 16 Bit Opcode meanings
-
-Ok, here is appropriate to raise an idea how to cover RVC and future
-variants, including RV16.
-
-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 "solution".
-
-The correct thing to do is, again, just like with foreign archs, to
-treat RVCs as a *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.
-
-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.
-
-# Why WARL will not work and why WLRL is required
+## Why WARL will not work and why WLRL is required
WARL requires a follow-up read of the CSR to ascertain what heuristic
the hardware *might* have applied, and if that procedure is followed in
be WLRL (on all platforms) and for traps to be mandatory (on the UNIX
Platform).
-# Is it strictly necessary for foreign archs to switch back? <a href="#foreignswitch"</a>
+## Is it strictly necessary for foreign archs to switch back? <a name="foreignswitch"></a>
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.
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
architecture implementation in a completely transparent fashion that in
no way interacts or interferes with this proposal.
+## Can we have dynamic declaration and runtime declaration of capabilities? <a name="dynamic"></a>
+
+Answer: don't know (yet). Quoted from Rogier:
+
+> "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."
+
+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 "git commit" to add globally-unique
+registered entries that map functionality to actual namespaces.
+
+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.
+
+at that point: yes, something akin to device-tree would be needed.
+
+# Open Questions <a name="open-questions"></a>
+
+This section from a post by Rogier Bruisse
+<http://hands.com/~lkcl/gmail_re_isadev_isamux.html>
+
+## is the ISANS CSR a 32 or XLEN bit value? <a name="isans-32-or-xlen"></a>
+
+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).
+
+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.
+
+## is the ISANS a flat number space or should some bits be reserved for use as flags?
+
+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 "paging" in the space currently
+occupied by RVC).
+
+## should the ISANS space be partitioned between reserved, custom with registration guaranteed non clashing, custom, very likely non clashing?
+
+Yes. Format TBD.
+
+## 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?
+
+This is almost certainly a software design issue, not so much a hardware
+issue.
+
+## How should the ISANS be (re)stored in a trap and in context switch?
+
+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.
+
+Quite simple.
+
+## Should the mechanism accommodate "foreign ISA's" and if so how does one restore the ISA.
+
+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.
+
+## Where is the default ISA stored and what is responsible for what it is after
+
+Options:
+* start up
+* starting a program
+* calling into a dynamically linked library
+* taking a trap
+* changing privilege levels
+
+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).
+
+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.
+
+The hardware is responsible for atomically switching out ISANS into the
+relevant xLAST-ISANS (and back again on exit). See Privileged Traps,
+above.
+
+## If the ISANS is just bits of an instruction that are to be prefixed by the cpu, can those bits contain immediates? Register numbers?
+
+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.
+
+This is what the CSRs are supposed to be for!
+
+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.
+
+## How does the system indicate a namespace is not recognised? Does it trap or can/must a recoverable mechanism be provided?
+
+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
+**MUST** be thrown (in the UNIX platform), and at that point it becomes the
+responsibility of software to deal with it.
+
+## What are the security implications? Can some ISA namespaces be set by user space?
+
+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.
+
+## Does the validity of an ISA namespace depend on privilege level? If so how?
+
+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.
+
+ISANS - through LAST-ISANS - is absolutely no different. The trap and the
+kernel (Supervisor or Hypervisor) are provided the *mechanism* by which
+ISA Namespace *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.
+
+
projects / libreriscv.git / blobdiff