binary-encoding of the context-switching information). (**TBD, Jacob,
separate page? review this para?**)
-# mvendorid/marchid WARL <a name="#mvendor_marchid_warl">
+# mvendorid/marchid WARL <a name="mvendor_marchid_warl"></a>
(Summary: the only idea that meets the full requirements. Needs
toolchain backup, but only when the first chip is released)
+This proposal has full details at the following page:
+[[mvendor_march_warl]]
+
Coming out of the software-related proposal by Jacob Bachmeyer, which
hinged on the idea of a globally-maintained gcc / binutils database
that kept and coordinated architectural encodings (curated by the Free
Software Foundation), was to quite simply make the mvendorid and marchid
-CSRs have WARL (writeable) characteristics. For instances where mvendorid
-and marchid are readable, that would be taken to be a Standards-mandatory
-"declaration" that the architecture has *no* Custom Extensions (and that
-it conforms precisely to one and only one specific variant of the
-RISC-V Specification).
+CSRs have WARL (writeable) characteristics. Read-only is taken to
+mean a declaration of "Having no Custom Extensions" (a zero-impact
+change).
+
+By making mvendorid-marchid tuples WARL the instruction decode phase
+may re-route mutually-exclusively to different engines, thus providing
+a controlled means and method of supporting multiple (future, past and
+present) versions of the **Base** ISA, Custom Extensions and even
+completely foreign ISAs in the same processor.
This incredibly simple non-invasive idea has some unique and distinct
advantages over other proposals:
an inner loop, with a single instruction (to the WARL register)
changing the meaning.
-A couple of points were made:
-
-* Compliance Testing may **fail** any system that has mvendorid/marchid
- as WARL. This however is a clear case of "Compliance Tail Wagging Standard
- Dog".
-* The redirection of meaning of certain binary encodings to multiple
- engines was considered extreme, eyebrow-raising, and also (importantly)
- potentially expensive, introducing significant latency at the decode
- phase.
-
-On this latter point, it was observed that MISA already switches out entire
-sets of instructions (interacts at the "decode" phase). The difference
-between what MISA does and the mvendor/march-id WARL idea is that whilst
-MISA only switches instruction decoding on (or off), the WARL idea
-*redirects* encoding, effectively to *different* simultaneous engines,
-fortunately in a deliberately mutually-exclusive fashion.
-
-Implementations would therefore, in each Extension (assuming one separate
-"decode" engine per Extension), simply have an extra (mutually-exclusively
-enabled) wire in the AND gate for any given binary encoding, and in this
-way there would actually be very little impact on the latency. The assumption
-here is that there are not dozens of Extensions vying for the same binary
-encoding (at which point the Fabless Semi Company has other much more
-pressing issues to deal with that make resolving binary encoding conflicts
-trivial by comparison).
-
-Also pointed out was that in certain cases pipeline stalls could be introduced
-during the switching phase, if needed, just as they may be needed for
-correct implementation of (mandatory) support for MISA.
-
**This is the only one of the proposals that meet the full requirements**
-Update 29apr2018:
-
-* In cases where mvendorid and marchid are WARL, the mvendorid-marchid becomes
- part of the execution context that must be saved (and switched as necessary)
- just like any other state / CSR.
-* When any trap exception is raised the context / state *must not* be altered
- (so that it can be properly saved, if needed, by the exception handler)
- and that includes the current mvendorid-marchid tuple. This leads to some
- interesting situations where a hart could conceivably be directed
- to a set of trap handler binary instructions that the current
- mvendorid-marchid setting is incapable of correctly interpreting.
- To fix this it will be necessary for implementations (hardware /
- software) to set up separate per-mvendorid-marchid trap handlers and
- for the hardware (or software) to switch to the appropriate trap "set".
-* It's been noted that there may be certain legitimate cases where an
- mvendorid-marchid should *specifically* not be tested for RISC-V
- Certification Compliance: native support for foreign architectures
- (not related to the JIT Extension: *actual* full entire non-RISC-V
- foreign instruction encoding). Exactly how this would work (vis-a-vis
- Compliance) needs discussion, as it would be unfortunate and
- undesirable for a hybrid processor capable of executing more than one
- hardware-level ISA support to not be permitted to receive RISC-V
- Certification Compliance.
-
-# ioctl-like <a name="#ioctl-like">
+# ioctl-like <a name="ioctl-like"></a>
(Summary: good solid orthogonal idea. See [[ioctl]] for full details)
TBD: placeholder as of 26apr2018
+## new (old) m-a-i tuple idea
+
+> actually that's a good point: where the user decides that they want
+> to boot one and only one tuple (for the entire OS), forcing a HARDWARE
+> level default m-a-i tuple at them actually prevents and prohibits them
+> from doing that, Jacob.
+>
+> so we have apps on one RV-Base ISA and apps on an INCOMPATIBLE (future)
+> variant of RV-Base ISA. with the approach that i was advocating (S-mode
+> does NOT switch automatically), there are totally separate mtvec /
+> stvec / bstvec traps.
+>
+> would it be reasonable to assume the following:
+>
+> (a) RV-Base ISA, particularly code-execution in the critical S-mode
+> trap-handling, is *EXTREMELY* unlikely to ever be changed, even thinking
+> 30 years into the future ?
+>
+> (b) if the current M-mode (user app level) context is "RV Base ISA 1"
+> then i would hazard a guess that S-mode is prettty much going to drop
+> down into *exactly* the same mode / context, the majority of the time
+>
+> thus the hypothesis is that not only is it the common code-path to *not*
+> switch the ISA in the S-mode trap but that the instructions used are
+> extremely unlikely to be changed between "RV Base Revisions".
+>
+> foreign isa hardware-level execution
+> ------------------------
+>
+> this is the one i've not really thought through so much, other than it
+> would clearly be disadvantageous for S-mode to be arbitrarily restricted
+> to running RV-Base code (of any variant). a case could be made that by the
+> time the m-a-i tuple is switched to the foreign isa it's "all bets off",
+> foreign arch is "on its own", including having to devise a means and
+> method to switch back (equivalent in its ISA of m-a-i switching).
+>
+> conclusion / idea
+> --------------------
+>
+> the multi-base "user wants to run one and only one tuple" is the key
+> case, here, that is a show-stopper to the idea of hard-wiring the default
+> S-mode m-a-i.
+>
+> now, if instead we were to say, "ok so there should be a default S-mode
+> m-a-i tuple" and it was permitted to SET (choose) that tuple, *that*
+> would solve that problem. it could even be set to the foreign isa.
+> which would be hilarious.
+
+
# Summary and Conclusion
In the early sections (those in the category "no action") it was established
> it is implementing. It will test nothing in the custom extension space,
> and doesn't monitor or care what is in that space.
+## (4) Jacob Bachmeyer on explaining disambiguation of opcode space
+
+> ...have different harts with different sets of encodings.) Adding a "select"
+> CSR as has been proposed does not escape this fundamental truth that
+> instruction decode must be unambiguous, it merely expands every opcode with
+> extra bits from a "select" CSR.
+
# References
* <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/7bbwSIW5aqM>
projects / libreriscv.git / blobdiff