This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] MIPS32 DSP intrinsics
- From: Mike Stump <mrs at apple dot com>
- To: Eric Christopher <echristo at redhat dot com>
- Cc: Nigel Stephens <nigel at mips dot com>, Chao-ying Fu <fu at mips dot com>, Richard Sandiford <rsandifo at redhat dot com>, "Thekkath, Radhika" <radhika at mips dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 1 Jun 2005 11:19:36 -0700
- Subject: Re: [PATCH] MIPS32 DSP intrinsics
On Wednesday, June 1, 2005, at 10:18 AM, Eric Christopher wrote:
True, however I don't want to put information that isn't available (and
likely still under NDA) into the public sources.
Trivially, if he didn't make me sign an NDA, then nothing he
contributes to gcc can be under NDA. If he makes it available to me
via the gcc-patches mailing list, then trivially, it is available.
If you think his management would fire him for breach of what ever
contract he has with them, well, you can ask them directly if you wish,
but, unless they can confirm his posting was a mistake, we should not
block it. Normally, we'd never even worry about this issue, that issue
is between him and his employer.
Further, I don't think we should require binutils sim support either,
that has never been a general requirement in the past, and should not
If we're generating the instructions I want some way to be able to test
I understand your concern. Just ignore his code, don't test it, don't
maintain it, require that he do it all for you. He he fails at doing
that, rip it all out, after he failed. I think it would be appropriate
for everyone else to maintain the code as they normally do and just
ignore the new DSP stuff, let Nigel build/test and QA it, let him
maintain it. If you break it on him, tough on him.
I don't see the harm is supporting the needs of Nigel here, really, I
don't. If it takes off, and his customers like what they are doing,
then other people will appreciate it as well, if it goes no where,
fine, we rip out the code. I think we should welcome him, and
encourage him, not shun him, block him and make him go away. I'd
rather have him as a maintainer, then to have him do what the moto
folks did with altivec, really.
I speak as someone that had to put in support for mips32 and mips64
long after the paper was written into gcc, this isn't a theoretic
I'd like to see all the silicon vendors submitting patches to support
their (major) needs (I hate the erata stuff), the problem is, they cost
earlier in the cycle than others would, and once it ships, they are
long since done with it and probably want to go on and do the next new
exciting thing. If we block them now, then we just have to do it later
by ourselves, or not have support, look at coldfire and its legacy.
Ick. Loot at altivec, which _still_ doesn't have the abi patches in
the FSF gcc to this date. :-( If they had been included in earlier,
gcc would have been better off and gcc users would have been better
off. Again, I speak from witnessing the actual horrors, not theoretic
So, why is is beneficial for gcc to not support the new DSP