This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]