Follow up on simulators, documentation, etc.

[Mark Mitchell]

Following the MIPS submission (for new intrinsics, for which no 
hardware, simulators, or official documentation was available), I raised 
the following question with the GCC SC:

>     The question is "should it be our policy to reject patches for 
>     instructions which there is no simulator, no silicon, and no ISA 
>     documentation?"

Opinions on the SC were pretty varied; I'm not sure it's safe to say 
there was a consensus.  Only a handful of people participated.  My 
(unofficial and unsactioned) summary of the opinions is that the middle 
ground was probably one of pragmatism: if it's useful to have such 
patches, and they're not too much of a burden, then accept the patches; 
otherwise, reject them.

The best judges of the costs and the benefits are almost certainly the 
maintainers for the back-end; in this case, Richard and Eric.  So, it's 
up to them to decide how to proceed in this particular case.

RMS posted the following message during the discussion, and has 
permitted me to re-post it (in its entirety) here.  That was the last 
message in the thread, and so probably as authoritative as anything.

> There is no need to have a uniform policy about it.  There is no
> compelling reason to treat all such cases alike.
> 
> Consider the case of machines that are available for use: we don't
> have to treat them all alike.  We don't have to support all of them;
> we support them when that serves our cause.  If a machine is rarely
> used and supporting it is a hassle, we can decide not to support it.
> 
> Likewise, when machines are not yet available, we don't have to
> support them, but we should do it if that seems advantageous for our
> cause.  Rather than prejudging all such situations in a blanket way, I
> would like you to judge the usefulness and the burden for each case,
> and make an individual decision.
> 
> The only special issue raised by such a situation is how to maintain
> the machine description.  We could not maintain it.  If the
> manufacturer is going to maintain it, that solves the problem.  So
> perhaps the thing to do is to ask the manufacturer to commit to
> maintaining the port it.  Perhaps until the chip and manual are
> available, or perhaps for as long as they want it to remain in the
> distribution.  Set whichever condition you see fit, and negotiate.
> 
>     Allowing the change to go in is risky for other reasons.  If the company
>     later decides that they won't release the chip ISA manual, even after the
>     chip is released, we are stuck with a major maintainence burdon.
> 
> We could always drop it if it becomes a burdon, so why worry too much
> about whether this *might* happen?
> 
> We can also inform the company, now, that we would have to drop it if
> it were not maintained.  That could be part of negotiating with them
> to get a commitment of support.
> 
> We could also ask them whether they plan to provide support for GDB
> and the binutils, or when they plan to release the manual so that
> others can do so.  This too could be part of the negotiation.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304