[PATCH] MIPS32 DSP intrinsics

[Mike Stump]

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.

Next.

>> 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
>> be now.
>
> If we're generating the instructions I want some way to be able to test
> them.

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

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

So, why is is beneficial for gcc to not support the new DSP 
instructions?