\paragraph{}
A fixed number of additional (hidden) bits, conceptually a \textbf{namespace},
-set by way of a CSR or other out-of-band mechanism,
+set by way of a \gls{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
\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}
+prevalent use for several decades (\gls{SPARC} and other architectures):
+dynamic runtime selectability of little-endian / big-endian \textbf{meaning}
of instructions by way of a \textbf{mode switch} instruction (of some kind).
\paragraph{}
\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.
+Note that this is a hypothetical format, yet to be decided, 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|
\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
+own completely separate PC. Thus, foreign assembly code and \gls{RISCV} assembly code
need not be mixed in the same binary.
\paragraph{}
\paragraph{}
-Switching CSR, PC (and potentially SP) and other state on a NS change in the
+Switching \gls{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{}
-Note 1: in the case of Supervisor Mode (context switches in particular),
+Note 1: in the case of \gls{SupervisorMode} (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 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
+8 possible completely new alternative meanings, just like how the \gls{Z80}
and the 286 and 386 used to do bank switching.
\paragraph{}
\paragraph{}
\textbf{These two communities would be mutually exclusively incompatible}. If
-a second emergency occurs, RISCV becomes even less tenable.
+a second emergency occurs, \gls{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
+\gls{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.
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
+into a (small, ICE40) \gls{FPGA}. 48-bit instruction decoding is much more complex
than straight 32-bit decoding, requiring a queue.
\paragraph{}
\paragraph{}
First: lack of coordination, in the proliferation of arbitrary solutions,
-has to primarily be borne by gcc, binutils, LLVM and other compilers.
+has to primarily be borne by \gls{gcc}, \gls{Binutils}, \gls{LLVM} and other compilers.
\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.
+what to do is to give the emulator a runtime command line argument.
\paragraph{}
Answer: don't know (yet). Quoted from Rogier:
\begin{quote}
-"A SOC may have several devices that one may want to directly control
+"A \gls{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
\paragraph{}
-dynamic detection wasn't originally planned: static
+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,
+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.
projects / libresoc-isa-manual.git / blobdiff