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
[EMAIL PROTECTED]
(916) 791-8304
