made efforts to point out that the consequences of not taking action
are clearly extreme and irreversible (which, unfortunately, given the
severity, some of the first group were unable to believe, despite there
-being clear historical precedent for the same mistake being made in
-other architectures).
+being clear historical precedent for the exact same mistake being made in
+other architectures, and the consequences on the same being absolutely
+clear).
However after a significant amount of time, certain clear requirements came
out of the discussion:
cope with (32-bit, 48-bit).
Overall, none of the options presented were feasible, and, in addition,
-even if they were followed through, still would result in the failure
-of the RISC-V ecosystem due to global conflicting ISA binary-encoding
-meanings (POWERPC's Altivec / SPE nightmare).
+with no clear leadership from the RISC-V Foundation on how to avoid
+global world-wide encoding conflict, even if they were followed through,
+still would result in the failure of the RISC-V ecosystem due to
+irreversible global conflicting ISA binary-encoding meanings (POWERPC's
+Altivec / SPE nightmare).
+
+This in addition to the case where the RISC-V Foundation wishes to
+fix a critical show-stopping update to the Standard, post-release,
+where billions of dollars have been spent on deploying RISC-V in the
+field.
# Do nothing (out of scope)
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 (*outside* of the control and remit of the
+RISC-V Foundation), 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
* MISA was only designed to cover Standard Extensions.
* There is nothing to prevent multiple Extensions being enabled
that wish to simultaneously interpret the same binary encoding.
+* There is nothing in the MISA specification which permits
+ *future* versions (bug-fixes) of the RISC-V ISA to be "switched in".
Overall, whilst the MISA concept is a step in the right direction it's
a hundred percent unsuitable for solving the problem.
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 of ISA decoding
+ could be done inside inner loops without adverse impact on
+ performance.
+
+Whilst it was the first "workable" solution it was also noted that the
+scheme is invasive: it requires an entirely new CSR to be added
+to the privileged spec (thus making existing implementations redundant).
+This does not 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 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.
+
+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
# Conclusion
-TBD
+In the early sections (those in the category "no action") it was established
+in each case that the problem is not solved. Avoidance of responsibility,
+or conflation of "not our problem" with "no problem" does not make "problem"
+go away.
+
+The first idea considered which could fix the problem was to just use
+the pre-existing MISA CSR, however this was determined not to have
+the right coverage (Standard Extensions only), and also crucially it
+destroyed state. Whilst unworkable it did lead to the first "workable"
+solution, "MISA-like".
+
+The "MISA-like" proposal, whilst meeting most of the requirements, led to
+a better idea: "mvendor/march-id WARL", which, in combination with an offshoot
+idea related to gcc and binutils, is the only proposal that fully meets the
+requirements.
+
+The "ioctl-like" idea *also* solves the problem, but, unlike the WARL idea
+does not meet the full requirements to be "non-invasive" and "backwards
+compatible" with pre-existing (pre-Standards-finalised) implementations.
+It does however stand on its own merit as a way to extend the extremely
+small Custom Extension opcode space, even if it itself implemented *as*
+a Custom Extension.
+
+Overall the mvendor/march-id WARL idea meets the three requirements,
+and is the only idea that meets the three requirements:
+
+* **Any proposal must be a minimal change with minimal (or zero) impact**
+ (met through being purely a single change to the specification:
+ mvendor/march-id changes from read-only to WARL)
+* **Any proposal should place no restriction on existing or future
+ ISA encoding space**
+ (met because it is just a change to one pre-existing CSR)
+* **Any proposal should take into account that there are existing implementors
+ of the (yet to be finalised but still "partly frozen") Standard who may
+ resist, for financial investment reasons, efforts to make any change
+ (at all) that could cost them immediate short-term profits.**
+ (met because existing implementations, with the exception of those
+ that have Custom Extensions, come under the "vendor/arch-id read only
+ is a declaration of having no Custom Extensions" fall-back category)
+
+So to summarise:
+
+* The consequences of not tackling this are severe: the RISC-V Foundation
+ cannot take a back seat. If it does, clear historical precedent shows
+ 100% what the outcome will be (1).
+* The retro-fitting cost onto existing implementations (even though the
+ specification has not been finalised) is negligeable
+ (changes to words in the specification)
+* The benefits are clear (pain-free transition path for vendors to safely
+ upgrade over time; no fights over Custom opcode space; no hassle for
+ software toolchain; no hassle for GNU/Linux Distros)
+* The implementation details are clear (and problem-free except for
+ vendors who insist on deploying dozens of conflicting Custom Extensions:
+ an extreme unlikely outlier).
+* Compliance Testing is straightforward and allows vendors to seek and
+ obtain *multiple* Compliance Certificates with past, present and future
+ variants of the RISC-V Standard (in the exact same processor), in order
+ support legacy customers and provide same customers with a way to avoid
+ "impossible-to-make" decisions that throw out ultra-expensive multi-decade
+ proprietary legacy software at the same as the hardware.
# Conversation Exerpts
> and typically the choice was "neither". Nobody wants to put in the
> effort when there is uncertainty and a market fragmented into
> small bits.
+>
> Note how Intel did not screw up. When SSE was added, MMX remained.
> Software vendors could trust that instructions would be supported.
> Both MMX and SSE remain today, in all shipping processors. With very
projects / libreriscv.git / blobdiff