Re: [PATCH] MIPS32 DSP intrinsics

[Steven Bosscher <stevenb at suse dot de>]

On Friday 03 June 2005 01:43, Mike Stump wrote:
> On Jun 2, 2005, at 3:12 PM, Steven Bosscher wrote:
> > Why is this not reasonable to ask of instruction sets implemented in a
> > free software compiler?
>
> What's next, requiring that we have ABI documents, scheduling and
> timing documents, machine code documents?

Whatever is relevant to the proposed patch.  Why are you ridiculing
this serious question.

> You require it, then you 
> get someone saying, you can't put this in, because the description on
> page 94 is wrong, where does it end?

It ends where the relevance of the documentation ends.  Obviously.

> Want to play with gcc, where's your papers, we need to see your
> papers?!  [ oh, wait, yeah, I guess we already do that ]

:-)

> Look at it this way, we serve the needs of mips.com, they make lots
> of money, they hire more people to work on gcc, life is good.

We serve the needs of mips.com at the cost of added complexity to
the compiler for something that we cannot verify nor guarantee to
our users to be correct, they make lots of money, period.
Or maybe they hire more people to work on more secret mips parts
of gcc, they make more money, period.
I don't see where the "life is good" comes in for gcc.

Now if we both leave black-and-white-land and be realistic: There
is absolutely no value in adding support for something that nobody
can use.  Richard Sandiford already offered to help by reviewing
the patches as far as he can, so that the patch can go in swiftly
"soon after the secrecy is lifted".  That looks very reasonable to
me for mips.com and for gcc.

> We 
> don't serve their needs, they go away, do their own compiler, and we
> get no help from them.

You're exaggerating the problem.

> We get to pick what we want, we should pick 
> carefully.  People should examine carefully the results of these
> types of decisions.

I believe that is what we are doing now, are we not?

> Look at Intel's i960 gcc compiler.  Look at 
> Moto's gcc compiler.  I'd say both were failures, let's just avoid
> engineering that type of solution.  It is better to bring them on
> board, even if they lead the edge, as then we have a leading edge
> compiler.

There is a difference between leading edge and supporting things that
are neither useful at this point to our users nor maintainable for
the port maintainers.  And all (two) port maintainers in this case
oppose having the instructions added at this time, doesn't that make
you wonder?

> If we wait until 2 years after the chips are out (when did 
> gcc get mmx/altivec support?), we are not a cutting edge compiler.

If you look at how things worked for amd64, I think it shows how a
chip manufacturer can choose to be open about things and get support
for their chip implemented in gcc even before silicon is available.

> Hint, I'm going to argue for the cutting edge compiler, it _is_
> better, better for us, better for gcc, better for mips.com customers,
> better for free software.

I think it is not better for us and for gcc until the documentation
is available, not better for free software because the only people
with useful access to the instructions are most likely not free
software developers (so in fact adding these instructions now will
probably give proprietary software vendors an edge, but let's enter
that political debate), and I would be very surprised to hear that
any mips.com customers would be so bold to use a gcc 4.1 development
snapshot for real work.

Gr.
Steven