considers Custom Extensions to be "out of scope"; that "it's not their
problem, therefore there isn't a problem".
-The logical errors in this argument were quickly enumerated: namely
-that the RISC-V Foundation is not in control of the use-cases, such
-that binary-encoding is a hundred percent guaranteed to occur, and
-a hundred percent guaranteed to occur in *commodity* hardware where
-Debian, Fedora, SUSE and other distros will be hardest hit by the
-resultant chaos, and that will just be the more "visible" aspect of
-the underlying problem.
+The logical errors in this argument were quickly enumerated: namely that
+the RISC-V Foundation is not in control of the uses to which RISC-V is
+put, such that public global conflicts in binary-encoding are a hundred
+percent guaranteed to occur, and a hundred percent guaranteed to occur in
+*commodity* hardware where Debian, Fedora, SUSE and other distros will
+be hardest hit by the resultant chaos, and that will just be the more
+"visible" aspect of the underlying problem.
# Do nothing (Compliance too complex, therefore out of scope)
TBD (basically, may not be RV Foundation's "scope", still results in
problem, so not an option)
+The summary here was that Compliance testing of Custom Extensions is
+not just out-of-scope, but even if it was taken into account that
+binary-encoding meanings could change, it would still be out-of-scope.
+
+However at the time that this argument was made, it had not yet been
+appreciated fully the impact that revisions to the Standard would have,
+when billions of dollars worth of (older, legacy) RISC-V hardware had
+already been deployed.
+
Two interestingly diametrically-opposed equally valid arguments exist here:
* Whilst Compliance testing of Custom Extensions is definitely legitimately
TBD, basically same as mvend/march WARL except needs an extra CSR where
mv/ma doesn't.
+Out of the MISA discussion came a "MISA-like" proposal, which would
+take into account the flaws pointed out by trying to use "MISA":
+
+* The MISA-like CSR's meaning would be identified by compilers using the
+ mvendor-id/march-id tuple as a compiler target
+* Each custom-defined bit of the MISA-like CSR would (mutually-exclusively)
+ redirect binary encoding(s) to specific encodings
+* No Extension would *actually* be disabled: its internal state would
+ be left on (permanently) so that switching could be done inside
+ inner loops.
+
+Whilst it was the first "workable" solution it was also noted that the
+scheme is quite invasive: it requires an entirely new CSR to be added
+to the privileged spec. This does not completely fulfil the "minimum
+impact" requirement.
+
+Also interesting around the same time an additional discussion was
+raised that covered the *compiler* side of the same equation. This
+revolved around using mvendorid-marchid tuples at the compiler level,
+to be put into assembly output (by gcc), preserving the required
+*globally* unique identifying information for binutils to successfully
+turn the custom instruction into an actual binary-encoding (plus
+binary-encoding of the context-switching information). (**TBD, Jacob,
+separate page? review this para?**)
+
# mvendorid/marchid WARL
TBD paraphrase and clarify
-> In an earlier part of the thread someone kindly pointed out that MISA
-> already switches out entire sets of instructions [which interacts at the
-> "decode" phase]. However it was noted after a few days of investigating
-> that particular lead that:
->
-> * MISA Extension disabling is permitted (optionally) to DESTROY the state
-> information (which means that it *has* to be re-initialised just to be
-> safe... mistake in the standard, there), and * MISA was only designed
-> to cover Standard Extensions.
->
-> So the practice of switching extensions in and out - and the resultant
-> "disablement" and "enablement" at the *instruction decode phase* is
-> *already* a hard requirement as part of conforming with the present
-> RISC-V Specification.
->
-> Around the same MISA discussion, someone else also kindly pointed out
-> that one solution to the heavyweight nature of the switching would
-> be to deliberately introduce a pipeline stall whilst the switching is
-> occurring: I can see the sense in that approach, even if I don't know the
-> full details of what each implementor might choose to do. They may even
-> choose two, or three, or N pipeline stalls: it really doesn't matter,
-> as it's an implementors' choice (and problem to solve).
->
-> So yes it's pretty heavy-duty... and also already required.
->
-> For the case where "legacy" variants of the RISC-V Standard are
-> backwards-forwards-compatibly supported over a 10-20 year period
-> in Industrial and Military/Goverment-procurement scenarios (so that
-> the impossible-to-achieve pressure is off to get the spec ABSOLUTELY
-> correct, RIGHT now), nobody would expect a seriously heavy-duty amount
-> of instruction-by-instruction switching: it'd be used pretty much once
-> and only once at boot-up (or once in a Hypervisor Virtual Machine client)
-> and that's it.
->
-> I can however foresee instances where implementors would actually
-> genuinely want a bank of operations to be carried out using one extension,
-> followed immediately by another bank from a (conflicting binary-encoding)
-> extension, in an inner loop: Software-defined MPEG / MP4 decode to call
-> DCT block decode Custom Extension followed immediately by Custom Video
-> Processing Extension followed immediately by Custom DSP Processing
-> Extension to do YUV-to-RGB conversion for example is something that
-> is clearly desirable. Solving that one would be entiiirely their
-> problem... and the RISC-V Specification really really should give them
-> the space to do that in a clear-cut unambiguous way.
+Coming out of the software-related proposal by Jacob, which hinged on
+the idea of a global gcc / binutils database that kept and coordinated
+architectural encodings, 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.
+
+This incredibly simple non-invasive idea has some unique and distinct
+advantages over other proposals:
+
+* Existing designs - even though the specification is not finalised
+ (but has "frozen" aspects) - would be completely unaffected: the
+ change is to the "wording" of the specification to "retrospectively"
+ fit reality.
+* Unlike with the MISA idea this is *purely* at the "decode" phase:
+ no internal Extension state information is permitted to be disabled,
+ altered or destroyed as a direct result of writing to the
+ mvendor/march-id CSRs.
+* Compliance Testing may be carried out with a different vendorid/marchid
+ tuple set prior to a test, allowing a vendor to claim *Certified*
+ compatibility with *both* one (or more) legacy variants of the RISC-V
+ Specification *and* with a present one.
+* With sufficient care taken in the implementation an implementor
+ may have multiple interpretations of the same binary encoding within
+ 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, to *different* 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 encoding conflicts trivial
+by comparison).
+
+Also pointed out was that in certain cases pipeline stalls could be introduced
+during the switching phase, if needed.
+
+**This is the only one of the proposals that meet the full requirements**
# ioctl-like
TBD - [[ioctl]] for full details, summary kept here
+This proposal basically mirrors the concept of POSIX ioctls, providing
+(arbitrarily) 8 functions (opcodes) whose meaning may be over-ridden
+in an object-orientated fashion by calling an "open handle" (and close)
+function (instruction) that switches (redirects) the 8 functions over to
+different opcodes.
+
+The proposal is functionally near-identical to that of the mvendor/march-id
+except extended down to individual opcodes. As such it could hypothetically
+be proposed as an independent Standard Extension in its own right that extends
+the Custom Opcode space *or* fits into the brownfield spaces within the
+existing ISA opcode space.
+
+One of the reasons for seeking an extension of the Custom opcode space is
+that the Custom opcode space is severely limited: only 2 opcodes are free
+within the 32-bit space, and only four total remain in the 48 and 64-bit
+space.
+
+Despite the proposal (which is still undergoing clarification)
+being worthwhile in its own right, and standing on its own merits and
+thus definitely worthwhile pursuing, it is non-trivial and much more
+invasive than the mvendor/march-id WARL concept.
+
# Discussion and analysis
TBD
projects / libreriscv.git / blobdiff