This is the mail archive of the gcc-patches@gcc.gnu.org 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


Thanks Mark. Much of what Mark is saying is the situation here.
BTW, I am the Director of Architecture at MIPS. 

We plan to have a processor core that implements the DSP ASE 
generally available (GA) by end of July. This patch is being 
sent now so that support for the new instructions can actually 
be present and accessible by any customer or anyone else for 
that matter at that time. We are aware that the patch needs 
to be reviewed and vetted before it is accepted, hence the 
2 month anticipation.

In general, a public version of a very new architecture is made
available at the same time that the first implementation is
available. Hence, in this case, we will have public versions
of the programmers instruction guides by end of July as well.
Hence, it is not a matter of the instructions being a secret,
but more a situation of ensuring that all the necessary
information is properly included in the full documentation 
before it is released. And this is only 2 months away.

We will do our utmost to provide support in the GCC simulator
for these instructions, but this will take time and effort
and we have to estimate when to get this done. We already support 
these instructions in our internal siumulator and we are 
constantly testing them since it is critical to us that the 
compiler be bug-free since we have application writers actively 
using it at this point.

------
Radhika Thekkath, Director of Architecture
Email: radhika@mips.com               MIPS Technologies Inc.
Voice: 650-567-5133                   1225 Charleston Road
Fax:   650-567-5002                   Mountain View, CA 94043
 


> Richard Sandiford wrote:
> 
> >>In either case, it's great to encourage these things, but we know that 
> >>users will want the compiler support, even if these things aren't 
> >>necessarily available.
> > 
> > 
> > ...my whole point is that, at the moment, most users _can't_ reasonably
> > use this stuff.  There's nothing to tell them what the instructions do,
> > and no publicly-available hardware for them to try it on.  That's my
> > understanding anyway.
> 
> Presumably, there will be such hardware soonish, and then users and 
> distributors who have GCC 4.1 will be all set.  If we wait to include 
> the bits until after there's more public information, then we won't have 
> support until some later point, and users who go out and buy the 
> hardware when it's released will lose.  I think it's reasonable for a 
> company to want to have released versions of GCC support their hardware 
> on the day that the hardware is first released.  And I think that's a 
> great thing for GCC; other compilers may not be as far along!
> 
> Of course, there may be lots of other reasons not to accept the code!  I 
> just don't think lack of simulators and/or docs should be one.  I think 
> it's in our long-term interest to encourage hardware vendors to invest 
> in GCC and if we require simulators/docs/hardware up front that will 
> discourage them, or encourage them to develop on private branches. 
> Either way, our FSF userbase loses.
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
> (916) 791-8304



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