2 % https://bugs.libre-soc.org/show_bug.cgi?id=214
8 A fixed number of additional (hidden) bits, conceptually a
\textbf{namespace
},
9 set by way of a
\gls{CSR
} or other out-of-band mechanism,
10 that go directly and non-optionally
11 into the instruction decode phase, extending (in each implementation) the
12 opcode length to
16+N,
32+N,
48+N, where N is a hard fixed quantity on
13 a per-implementor basis.
17 Where the opcode is normally loaded from the location at the PC, the extra
18 bits, set via a CSR, are mandatorially appended to every instruction: hence why
19 they are described as "hidden" opcode bits, and as a
\textbf{namespace
}.
23 The parallels with c++
\textbf{using namespace
} are direct and clear.
24 Alternative conceptual ways to understand this concept include
25 \textbf{escape-sequencing
}.
29 TODO: reserve some bits which permit the namespace
\textbf{escape-sequence
} to
30 be relevant for a fixed number of instructions at a time. Caveat:
31 allowing such a countdown to cross branch-points is unwise (illegal
36 An example of a pre-existing
\textbf{namespace
} switch that has been in
37 prevalent use for several decades (
\gls{SPARC
} and other architectures):
38 dynamic runtime selectability of little-endian / big-endian
\textbf{meaning
}
39 of instructions by way of a
\textbf{mode switch
} instruction (of some kind).
43 That
\textbf{switch
} is in effect a
33rd (hidden) bit that is part of the opcode,
44 going directly into the mux / decode phase of instruction decode, and
45 thus qualifies categorically as a
\textbf{namespace
}. This proposal both formalises
46 and generalises that concept.
48 \section{Hypothetical Format
} \label{hypotheticalformat
}
52 Note that this is a hypothetical format, yet to be decided, where particular
53 attention needs to be paid to the fact that there is an
\textbf{immediate
}
54 version of CSRRW (with
5 bits of immediate) that could save a lot of space in
59 |
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|
60 |-------------------------------|-------|---------------------|-|
61 |
1 custom custom custom custom custom | foreignarch |
1|
62 |
0 reserved reserved reserved reserved reserved | foreignarch |
1|
63 |custom | reserved | official|B| rvcpage |
0|
76 when bit
0 is
0,
\textbf{RV
} mode is selected.
80 in RV mode, bits
1 thru
5 provide up to
16 possible alternative meanings
81 (namespaces) for
16 Bit opcodes.
\textbf{pages
} if you will. The top bit
82 indicates custom meanings. When set to
0, the top bit is for official usage.
86 Bits
15 thru
23 are reserved.
90 Bits
24 thru
31 are for custom usage.
94 bit
6 (
\textbf{B
}) is
\gls{endian
}-selection:
\gls{LE
}/
\gls{BE
}
100 16 bit page examples:
108 0b0000 STANDARD (
2019) RVC
128 0b1000 custom
16 bit opcode meanings
1
132 0b1001 custom
16 bit opcode meanings
2
150 when bit
0 (the
\gls{LSB
}) is
1,
\textbf{Foreign arch
} mode is selected.
151 % part of the reason for having LSB here is to avoid glossary ordering problems
155 Bits
1 thru
7 are a table of foreign arches.
159 when the
\gls{MSB
} is
1, this is for custom use.
163 when the MSB is
0, bits
1 thru
6 are reserved for
64 possible official foreign archs.
169 Foreign archs could be (examples):
197 0b0010000 Java Bytecode
201 0b0010001 N.E.Other Bytecode
209 0b1000000 custom foreign arch
1
213 0b1000001 custom foreign arch
2
223 Note that
\textbf{official
} foreign archs have a binary value where the MSB is zero,
224 and custom foreign archs have a binary value where the MSB is
1.
226 \section{Namespaces are permitted to swap to new state
} \label{stateswap
}
230 In each privilege level, on a change of ISANS (whether through manual setting
231 of ISANS or through trap entry or exit changing the ISANS CSR), an
232 implementation is permitted to completely and arbitrarily switch not only the
233 instruction set, it is permitted to switch to a new bank of CSRs (or a subset
234 of the same), and even to switch to a new PC.
238 This to occur immediately and atomically at the point at which the change in ISANS occurs.
242 The most obvious application of this is for Foreign Archs, which may have their
243 own completely separate PC. Thus, foreign assembly code and
\gls{RISCV
} assembly code
244 need not be mixed in the same binary.
248 Further use-cases may be envisaged however great care needs to be taken to not
249 cause massive complications for JIT emulation, as the RV ISANS is unary encoded
250 (
2\^
31 permutations).
254 In addition, the state information of
\textbf{all
} namespaces has to be saved
255 and restored on a context-switch (unless the SP is also switched as part of the
256 state!) which is quite severely burdensome and getting exceptionally complex.
260 Switching
\gls{CSR
},
\gls{PC
} (and potentially
\gls{SP
}) and other state on a NS change in the
261 RISCV unary NS therefore needs to be done wisely and responsibly, i.e.
266 To be discussed. Context
267 href=https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/\\
268 x-uFZDXiOxY/
27QDW5KvBQAJ
271 \section{Privileged Modes / Traps
} \label{privtraps
}
275 An additional WLRL CSR per priv-level named
\textbf{LAST-ISANS
} is required, and
276 another called
\textbf{TRAP-ISANS
}
277 These mirrors the ISANS CSR, and, on a trap, the current ISANS in
278 that privilege level is atomically
279 transferred into LAST-ISANS by the hardware, and ISANS in that trap
280 is set to TRAP-ISANS. Hardware is
\textbf{only then
} permitted to modify the
\gls{PC
} to
281 begin execution of the trap.
285 On exit from the trap, LAST-ISANS is copied into the ISANS CSR, and
286 LAST-ISANS is set to TRAP-ISANS.
\textbf{Only then
} is the hardware permitted
287 to modify the PC to begin execution where the trap left off.
291 This is identical to how xepc is handled.
295 Note
1: in the case of
\gls{SupervisorMode
} (context switches in particular),
296 saving and changing of LAST-ISANS (to and from the stack) must be done
297 atomically and under the protection of the SIE bit. Failure to do so
298 could result in corruption of LAST-ISANS when multiple traps occur in
299 the same privilege level.
303 Note
2: question - should the trap due to illegal (unsupported) values
304 written into LAST-ISANS occur when the
\textbf{software
} writes to LAST-ISANS,
305 or when the
\textbf{trap
} (on exit) writes into LAST-ISANS? this latter seems
306 fraught: a trap, on exit, causing another trap??
310 Per-privilege-level pseudocode (there exists UISANS, UTRAPISANS, ULASTISANS,
311 MISANS, MTRAPISANS, MLASTISANS and so on):
316 LAST-ISANS = ISANS // record the old NS
317 ISANS = TRAP_ISANS // traps are executed in "trap" NS
325 LAST-ISANS = TRAP_ISANS
329 \section{Alternative RVC
16 Bit Opcode meanings
} \label{alternativervc16bitopcodemeanings
}
333 Here is appropriate to raise an idea how to cover RVC and future
334 variants, including RV16.
338 Just as with foreign archs, and you quite rightly highlight above, it
339 makes absolutely no sense to try to select both RVCv1, v2, v3 and so on,
340 all simultaneously. An unary bit vector for RVC modes, changing the
16
341 BIT opcode space meaning, is wasteful and again has us believe that WARL
342 is the
\textbf{solution
}.
346 The correct thing to do is, again, just like with foreign archs, to
347 treat RVCs as a
\textbf{binary
} namespace selector. Bits
1 thru
3 would give
348 8 possible completely new alternative meanings, just like how the
\gls{Z80
}
349 and the
286 and
386 used to do bank switching.
353 All zeros is clearly reserved for the present RVC.
0b001 for RVCv2.
0b010
354 for RV16 (look it up) and there should definitely be room reserved here
355 for custom reencodings of the
16 bit opcode space.
357 \section{FAQ
}\label{faq
}
359 \subsection{Why not have TRAP-ISANS as a vector table, matching mtvec?
} \label{trap-isans-vec
}
363 Use case to be determined. Rather than be a global per-priv-level value,
364 TRAP-ISANS is a table of length exactly equal to the mtvec/utvec/stvec table,
365 with corresponding entries that specify the assembly-code namespace in which
366 the trap handler routine is written.
370 Open question: see https://groups.google.com/a/groups.riscv.org/d/msg/isa\-dev/IAhyOqEZoWA/BM0G3J2zBgAJ
375 LAST-ISANS = ISANS // record the old NS
376 ISANS = TRAP_ISANS_VEC
[xcause
] // traps are executed in "trap" NS
384 LAST-ISANS = TRAP_ISANS_VEC
[x_cause
]
388 \subsection{Is this like MISA ?
} \label{misa
}
400 \gls{MISA
}'s space is entirely taken up (and running out).
404 There is no allocation (provision) for custom extensions.
408 MISA switches on and off entire extensions:
\gls{ISAMUX
}/NS may be used to switch
409 multiple opcodes (present and future), to alternate meanings.
413 MISA is WARL and is inaccessible from everything but M-Mode (not even readable).
419 MISA is therefore wholly unsuited to U-Mode usage; ISANS is specifically
420 permitted to be called by userspace to switch (with no stalling) between
421 namespaces, repeatedly and in quick succession.
423 \subsection{What happens if this scheme is not adopted? Why is it better than leaving things well alone?
} \label{laissezfaire
}
427 At the first sign of an emergency non-backwards compatible and unavoidable
428 change to the
\textbf{frozen
} RISCV
\textbf{official
} Standards, the entire RISCV
429 community is fragmented and divided into two:
437 Those vendors that are hardware compatible with the legacy standard.
441 Those that are compatible with the new standard.
447 \textbf{These two communities would be mutually exclusively incompatible
}. If
448 a second emergency occurs,
\gls{RISCV
} becomes even less tenable.
452 Hardware that wished to be
\textbf{compatible
} with either flavour would require
453 \gls{JIT
} or offline static binary recompilation. No vendor would willingly
454 accept this as a condition of the standards divergence in the first place,
455 locking up decision making to the detriment of RISCV as a whole.
459 By providing a
\textbf{safety valve
} in the form of a hidden namespace, at least
460 newer hardware has the option to implement both (or more) variations,
461 \textbf{and still apply for Certification
}.
465 However to also allow
\textbf{legacy
} hardware to at least be JIT soft
466 compatible, some very strict rules
\textbf{must
} be adhered to, that appear at
467 first sight not to make any sense.
471 It's complicated in other words!
473 \subsection{Surely it's okay to just tell people to use
48-bit encodings?
} \label{use48bit
}
477 Short answer: it doesn't help resolve conflicts, and costs hardware and
478 redesigns to do so. Softcores in cost-sensitive embedded applications may
479 even not actually be able to fit the required
48 bit instruction decode engine
480 into a (small, ICE40)
\gls{FPGA
}.
48-bit instruction decoding is much more complex
481 than straight
32-bit decoding, requiring a queue.
485 Second answer: conflicts can still occur in the (unregulated, custom)
48-bit
486 space, which
\textbf{could
} be resolved by ISAMUX/ISANS as applied to the
\textbf{48} bit
487 space in exactly the same way. And the
64-bit space.
489 \subsection{Why not leave this to individual custom vendors to solve on a case by case basis?
} \label{case-by-case
}
493 The suggestion was raised that a custom extension vendor could create
494 their own CSR that selects between conflicting namespaces that resolve
495 the meaning of the exact same opcode. This to be done by all and any
496 vendors, as they see fit, with little to no collaboration or coordination
497 towards standardisation in any form.
501 The problems with this approach are numerous, when presented to a
502 worldwide context that the UNIX Platform, in particular, has to face
503 (where the embedded platform does not)
507 First: lack of coordination, in the proliferation of arbitrary solutions,
508 has to primarily be borne by
\gls{gcc
},
\gls{Binutils
},
\gls{LLVM
} and other compilers.
512 Secondly: CSR space is precious. With each vendor likely needing only one
513 or two bits to express the namespace collision avoidance, if they make
514 even a token effort to use worldwide unique CSRs (an effort that would
515 benefit compiler writers), the CSR register space is quickly exhausted.
519 Thirdly: JIT Emulation of such an unregulated space becomes just as
520 much hell as it is for compiler writers. In addition, if two vendors
521 use conflicting CSR addresses, the only sane way to tell the emulator
522 what to do is to give the emulator a runtime command line argument.
526 Fourthly: with each vendor coming up with their own way of handling
527 conflicts, not only are the chances of mistakes higher, it is against the
528 very principles of collaboration and cooperation that save vendors money
529 on development and ongoing maintenance. Each custom vendor will have
530 to maintain their own separate hard fork of the toolchain and software,
531 which is well known to result in security vulnerabilities.
535 By coordinating and managing the allocation of namespace bits (unary
536 or binary) the above issues are solved. CSR space is no longer wasted,
537 compiler and JIT software writers have an easier time, clashes are
538 avoided, and RISCV is stabilised and has a trustable long term future.
540 \subsection{ Why ISAMUX / ISANS has to be WLRL and mandatory trap on illegal writes
} \label{wlrlmandatorytrap
}
544 The namespaces, set by bits in the CSR, are functionally directly
545 equivalent to c++ namespaces, even down to the use of braces.
549 WARL, by allowing implementors to choose the value, prevents and prohibits
550 the critical and necessary raising of an exception that would begin the
551 JIT process in the case of ongoing standards evolution.
555 Without this opportunity, an implementation has no reliable guaranteed way of knowing
556 when to drop into full JIT mode,
557 which is the only guaranteed way to distinguish
558 any given conflicting opcode. It is as if the c++
559 standard was given a similar optional
560 opportunity to completely ignore the
561 \textbf{using namespace
} prefix!
569 Ok so I trust it's now clear why WLRL (thanks Allen) is needed.
573 When Dan raised the WARL concern initially a situation was masked by
574 the conflict, that if gone unnoticed would jeapordise ISAMUX/ISANS
575 entirely. Actually, two separate errors. So thank you for raising the
580 The situation arises when foreign archs are to be given their own NS
581 bit. MIPS is allocated bit
8, x86 bit
9, whilst LE/BE is given bit
0,
582 RVCv2 bit
1 andso on. All of this potential rather than actual, clearly.
586 Imagine then that software tries to write and set not just bit
8 and
587 bit
9, it also tries to set bit
0 and
1 as well.
591 This
\textbf{IS
} on the face of it a legitimate reason to make ISAMUX/ISANS WARL.
595 However it masks a fundamental flaw that has to be addressed, which
596 brings us back much closer to the original design of
18 months ago,
597 and it's highlighted thus:
601 x86 and simultaneous RVCv2 modes are total nonsense in the first place!
605 The solution instead is to have a NS bit (bit0) that SPECIFICALLY
606 determines if the arch is RV or not. If
0, the rest of the ISAMUX/ISANS
607 is very specifically RV
\textbf{only
}, and if
1, the ISAMUX/ISANS is a
\textbf{binary
}
608 table of foreign architectures and foreign architectures only.
612 Exactly how many bits are used for the foreign arch table, is to
613 be determined.
7 bits, one of which is reserved for custom usage,
614 leaving a whopping
64 possible
\textbf{official
} foreign instruction sets to
615 be hardware-supported/JIT-emulated seems to be sufficiently gratuitous,
620 One of those could even be Java Bytecode!
624 Now, it could
\textbf{hypothetically
} be argued that the permutation of setting
625 LE/BE and MIPS for example is desirable. A simple analysis shows this
626 not to be the case: once in the MIPS foreign NS, it is the MIPS hardware
627 implementation that should have its own way of setting and managing its
628 LE/BE mode, because to do otherwise drastically interferes with MIPS
629 binary compatibility.
633 Thus, it is officially Not Our Problem: only flipping into one foreign
634 arch at a time makes sense, thus this has to be reflected in the
635 ISAMUX/ISANS CSR itself, completely side-stepping the (apparent) need
636 to make the NS CSR WARL (which would not work anyway, as previously
641 So, thank you, again, Dan, for raising this. It would have completely
642 jeapordised ISAMUX/NS if not spotted.
646 The second issue is: how does any hardware system, whether it support
647 ISANS or not, and whether any future hardware supports some Namespaces
648 and, in a transitive fashion, has to support
\textbf{more
} future namespaces,
649 through JIT emulation, if this is not planned properly in advance?
653 Let us take the simple case first: a current
2019 RISCV fully compliant
654 RV64GC UNIX capable system (with mandatory traps on all unsupported CSRs).
658 Fast forward
20 years, there are now
5 ISAMUX/NS unary bits, and
3
659 foreign arch binary table entries.
663 Such a system is perfectly possible of software JIT emulating ALL of these
664 options because the write to the (illegal, for that system) ISAMUX/NS
665 CSR generates the trap that is needed for that system ti begin JIT mode.
669 (This again emphasises exactly why the trap is mandatory).
673 Now let us take the case of a hypothetical system from say
2021 that
674 implements RVCv2 at the hardware level.
678 Fast forward
20 years: if the CSR were made WARL, that system would be
679 absolutely screwed. The implementor would be under the false impression
680 that ignoring setting of
\textbf{illegal
} bits was acceptable, making the
681 transition to JIT mode flat-out impossible to detect.
685 When this is considered transitively, considering all future additions to
686 the NS, and all permutations, it can be logically deduced that there is
687 a need to reserve a
\textbf{full
} set of bits in the ISAMUX/NS CSR
\textbf{in advance
}.
691 i.e. that
\textbf{right now
}, in the year
2019, the entire ISAMUX/NS CSR cannot
692 be added to piecemeal, the full
32 (or
64) bits
\textbf{has
} to be reserved,
693 and reserved bits set at zero.
697 Furthermore, if any software attempts to write to those reserved bits,
698 it
\textbf{must
} be treated just as if those bits were distinct and nonexistent
699 CSRs, and a trap raised.
703 It makes more sense to consider each NS as having its own completely
704 separate CSR, which, if it does not exist, clearly it should be obvious
705 that, as an unsupported CSR, a trap should be raised (and JIT emulation
710 However given that only the one bit is needed (in RV NS Mode, not
711 Foreign NS Mode), it would be terribly wasteful of the CSRs to do this,
712 despite it being technically correct and much easier to understand why
713 trap raising is so essential (mandatory).
717 This again should emphasise how to mentally get one's head round this
718 mind-bendingly complex problem space: think of each NS bit as its own
719 totally separate CSR that every implementor is free and clear to implement
720 (or leave to JIT Emulation) as they see fit.
724 Only then does the mandatory need to trap on write really start to hit
725 home, as does the need to preallocate a full set of reserved zero values
730 Lastly, I
\textbf{think
} it's ok to only reserve say
32 bits, and, in
50 years
731 time if that genuinely is not enough, start the process all over again
732 with a new CSR. ISAMUX2/NS2.
736 Subdivision of the RV NS (support for RVCv3/
4/
5/RV16 without wasting
737 precious CSR bits) best left for discussion another time, the above is
738 a heck of a lot to absorb, already.
740 \subsection{Why WARL will not work and why WLRL is required
}
744 WARL requires a follow-up read of the CSR to ascertain what heuristic
745 the hardware
\textbf{might
} have applied, and if that procedure is followed in
746 this proposal, performance even on hardware would be severely compromised.
750 In addition when switching to foreign architectures, the switch has to
751 be done atomically and guaranteed to occur.
755 In the case of JIT emulation, the WARL
\textbf{detection
} code will be in an
756 assembly language that is alien to hardware.
760 Support for both assembly languages immediately after the CSR write
761 is clearly impossible, this leaves no other option but to have the CSR
762 be WLRL (on all platforms) and for traps to be mandatory (on the UNIX
765 \subsection{Is it strictly necessary for foreign archs to switch back?
} \label{foreignswitch
}
769 No, because LAST-ISANS handles the setting and unsetting of the ISANS CSR
770 in a completely transparent fashion as far as the foreign arch is concerned.
771 Supervisor or Hypervisor traps take care of the context switch in a way
772 that the user mode (or guest) need not be aware of, in any way.
776 Thus, in e.g. Hypervisor Mode, the foreign guest arch has no knowledge
777 or need to know that the hypervisor is flipping back to RV at the time of
782 Note however that this is
\textbf{not
} the same as the foreign arch executing
783 \textbf{foreign
} traps! Foreign architecture trap and interrupt handling mechanisms
784 are
\textbf{out of scope
} of this
document and MUST be handled by the foreign
785 architecture implementation in a completely transparent fashion that in
786 no way interacts or interferes with this proposal.
788 \subsection{Can we have dynamic declaration and runtime declaration of capabilities?
} \label{dynamic
}
792 Answer: don't know (yet). Quoted from Rogier:
795 "A
\gls{SoC
} may have several devices that one may want to directly control
796 with custom instructions. If independent vendors use the same opcodes you
797 either have to change the encodings for every different chip (not very
798 nice for software) or you can give the device an ID which is defined in
799 some device tree or something like that and use that."
804 Dynamic detection wasn't originally planned: static
805 compilation was envisaged to solve the need, with a table of
806 mvendorid-marchid-isamux/isans being maintained inside gcc / binutils /
807 llvm (or separate library?) that, like the Linux kernel ARCH table,
808 requires a world-wide atomic
\textbf{git commit
} to add globally-unique
809 registered entries that map functionality to actual namespaces.
813 where that goes wrong is if there is ever a pair (or more) of vendors
814 that use the exact same custom feature that maps to different opcodes,
815 a statically-compiled binary has no hope of executing natively on both
820 at that point: yes, something akin to device-tree would be needed.
822 \section{Open Questions
}\label{open-questions
}
826 This section from a post by Rogier Bruisse
827 \href{http://hands.com/~lkcl/gmail_re_isadev_isamux.html
}{http://hands.com/~lkcl/gmail
\_re\_isadev\_isamux.html
}
829 \subsection{is the ISANS CSR a
32 or XLEN bit value?
} \label{isans-
32-or-xlen
}
833 This is partly answered in another FAQ above: if
32 bits is not enough
834 for a full suite of official, custom-with-atomic-registration and custom-without
835 then a second CSR group (ISANS2) may be added at a future date (
10-
20 years
840 32 bits would not inconvenience RV32, and implementors wishing to
841 make significant altnernative modifications to opcodes in the RV32 ISA space
842 could do so without the burden of having to support a split
32/LO
32/HI
843 CSR across two locations.
845 \subsection{Is the ISANS a flat number space or should some bits be reserved for use as flags?
}
849 See
16-bit RV namespace "page" concept, above. Some bits have to be unary
850 (multiple simultaneous features such as LE/BE in one bit, and augmented
851 Floating-point rounding / clipping in another), whilst others definitely
852 need to be binary (the most obvious one being
\textbf{paging
} in the space currently
855 \subsection{Should the ISANS space be partitioned between reserved, custom with registration guaranteed non clashing, custom, very likely non clashing?
}
861 \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?
}
865 This is almost certainly a software design issue, not so much a hardware
868 \subsection{How should the ISANS be (re)stored in a trap and in context switch?
}
872 See section above on privilege mode: LAST-ISANS has been introduced that
873 mirrors (x)CAUSE and (x)EPC pretty much exactly. Context switches change
874 uepc just before exit from the trap, in order to change the user-mode PC
875 to switch to a new process, and ulast-isans can - must - be treated in
876 exactly the same way. When the context switch sets ulast-isans (and uepc),
877 the hardware flips both ulast-isans into uisans and uepc into pc (atomically):
878 both the new NS and the new PC activate immediately, on return to usermode.
884 \subsection{Should the mechanism accommodate "foreign ISA's" and if so how does one restore the ISA.
}
888 See section above on LAST-ISANS. With the introduction of LAST-ISANS, the
889 change is entirely transparent, and handled by the Supervisor (or Hypervisor)
890 trap, in a fashion that the foreign ISA need not even know of the existence
893 \subsection{Where is the default ISA stored and what is responsible for what it is after
}
912 calling into a dynamically linked library
920 changing privilege levels
926 These first four are entirely at the discretion of (and the
927 responsibility of) the software. There is precedent for most of these
928 having been implemented, historically, at some point, in relation to
929 LE/BE mode CSRs in other hardware (MIPSEL vs MIPS distros for example).
933 Traps are responsible for saving LAST-ISANS on the stack, exactly as they
934 are also responsible for saving other context-sensitive information such
935 as the registers and xEPC.
939 The hardware is responsible for atomically switching out ISANS into the
940 relevant xLAST-ISANS (and back again on exit). See Privileged Traps,
943 \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?
}
947 The concept of a CSR containing an immediate makes no sense. The concept
948 of a CSR containing a register number, the contents of which would, presumably,
949 be inserted into the NS, would immediately make that register a permanent
950 and irrevocably reserved register that could not be utilised for any other
955 This is what the CSRs are supposed to be for!
959 It would be better just to have a second CSR - ISANS2 - potentially even ISANS3
960 in
60+ years time, rather than try to use a GPR for the purposes for which CSRs
963 \subsection{How does the system indicate a namespace is not recognised? Does it trap or can/must a recoverable mechanism be provided?
}
967 It doesn't "indicate" that a namespace is not recognised. WLRL fields only
968 hold supported values. If the hardware cannot hold the value, a trap
969 \textbf{MUST
} be thrown (in the UNIX platform), and at that point it becomes the
970 responsibility of software to deal with it.
972 \subsection{What are the security implications? Can some ISA namespaces be set by user space?
}
976 Of course they can. It becomes the responsibility of the Supervisor Mode
977 (the kernel) to treat ISANS in a fashion orthogonal to the PC. If the OS
978 is not capable of properly context-switching securely by setting the right
979 PC, it's not going to be capable of properly looking after changes to ISANS.
981 \subsection{Does the validity of an ISA namespace depend on privilege level? If so how?
}
985 The question does not exactly make sense, and may need a re-reading of the
986 section on how Privilege Modes, above. In RISC-V, privilege modes do not
987 actually change very much state of the system: the absolute minimum changes
988 are made (swapped out) - xEPC, xSTATUS and so on - and the privilege mode
989 is expected to handle the context switching (or other actions) itself.
993 ISANS - through LAST-ISANS - is absolutely no different. The trap and the
994 kernel (Supervisor or Hypervisor) are provided the
\textbf{mechanism
} by which
995 ISA Namespace
\textbf{may
} be set: it is up to the software to use that mechanism
996 correctly, just as the software is expected to use the mechanisms provided
997 to correctly implement context-switching by saving and restoring register
998 files, the PC, and other state. The NS effectively becomes just another