add ioctl page

[libreriscv.git] / isa_conflict_resolution.mdwn

# Resolving ISA conflicts and providing a pain-free RISC-V Standards Upgrade Path

In a lengthy thread that ironically was full of conflict indicative
of the future direction in which RISC-V will go if left unresolved,
multiple Custom Extensions were noted to be permitted free rein to
introduce global binary-encoding conflict with no means of resolution
described or endorsed by the RISC-V Standard: a practice that has known
disastrous and irreversible consequences for any architecture that
permits such practices (1).

Much later on in the discussion it was realised that there is also no way
within the current RISC-V Specification to transition to improved versions
of the standard, regardless of whether the fixes are absolutely critical
show-stoppers or whether they are just keeping the standard up-to-date (2).

It was also pointed out that Compliance is an extremely important factor
to take into consideration, and that Custom Extensions (as being optional)
effectively fall entirely outside of the Compliance Testing.  At this
point in the discussion however it was not yet noted the stark problem
that the *mandatory* RISC-V Specification also faces, by virtue of there
being no transitional way to bring in show-stopping critical alterations.

To put this into perspective, just taking into account hardware costs
alone: with production mask charges for 28nm being around USD $1.5m,
engineering development costs and licensing of RTLs for peripherals
being of a similar magnitude, no manufacturer is going to back away
from selling a "flawed" or "legacy" product (whether it complies with
the RISC-V Specification or not) without a bitter fight.

It was also pointed out that there will be significant software tool
maintenance costs for manufacturers, meaning that the probability will
be extremely high that they will refuse to shoulder such costs, and
publish hopelessly out-of-date unpatched tools.  This practice is
well-known to result in security flaws going unpatched, with one
of many immediate consequences being that product gets discarded into
landfill.

All and any of the issues that were discussed, and all of those that
were not, can be avoided by providing a forwards and backwards
compatible transition path between the current and future *mandatory*
parts of revisions of the RISC-V ISA Standard.

The rest of the discussion - indicative as it was of the stark mutually
exclusive gap being faced by the RISC-V ISA Standard given that it does
not cope with the problem - was an effort by two groups in two clear
camps: one that wanted things to remain as they are, and another that
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).

However after a significant amount of time, certain clear requirements came
out of the discussion:

* Any proposal must be a minimal change with minimal (or zero) impact
* Any proposal should place no restriction on existing or future
  ISA encoding space
* 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.

Several proposals were put forward (and some are still under discussion)

* "Do nothing": problem is not severe: no action needed.
* "Do nothing": problem is out-of-scope for RISC-V Foundation.
* "MISA": the MISA CSR enables and disables extensions already: use that
* "MISA-like": a new CSR which switches in and out new encodings
  (without destroying state)
* "mvendorid/marchid WARL": switching the entire "identity" of a machine
* "ioctl-like": a OO proposal based around the linux kernel "ioctl" system.

Each of these will be discussed below in their own sections.

# Do nothing (no problem exists)

TBD (basically not an option).

# Do nothing (out of scope)

TBD (basically, may not be RV Foundation's "scope", still results in
problem, so not an option)

# MISA

TBD, basically MISA not suitable

> * 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.
 
# MISA-like

TBD, basically same as mvend/march WARL except needs an extra CSR where
mv/ma doesn't.

# 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.

# ioctl-like

TBD - [[ioctl]] for full details, summary kept here

# Discussion and analysis

TBD

# Conclusion

TBD

# Conversation Exerpts

The following conversation exerpts are taken from the ISA-dev discussion

## (1) Albert Calahan on SPE / Altiven conflict in POWERPC

> Yes. Well, it should be blocked via legal means. Incompatibility is
> a disaster for an architecture.
> 
> The viability of PowerPC was badly damaged when SPE was
> introduced. This was a vector instruction set that was incompatible
> with the AltiVec instruction set. Software vendors had to choose,
> 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
> few exceptions, Intel does not ship chips with missing functionality.
> There is a unified software ecosystem.
> 
> This goes beyond the instruction set. MMU functionality also matters.
> You can add stuff, but then it must be implemented in every future CPU.
> You can not take stuff away without harming the architecture.

## (2) Luke Kenneth Casson Leighton on Standards backwards-compatibility

> 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.

## (3) Allen Baum on Standards Compliance

> Putting my compliance chair hat on: One point that was made quite
> clear to me is that compliance will only test that an implementation
> correctly implements the portions of the spec that are mandatory, and
> the portions of the spec that are optional and the implementor claims
> it is implementing. It will test nothing in the custom extension space,
> and doesn't monitor or care what is in that space.