[vsipl++] [patch] Config update

[Mark Mitchell]

Brooks Moses wrote:
> Jules Bergmann wrote, at 1/29/2008 2:04 PM:
>>> As an addendum -- for Cell, we settled on powerpc-cell-linux-gnu for the
>>> canonical triplet when documenting the --host option; I think it would
>>> be good to have this agree with that.
>> Sounds fine to me.  To be sure I understand the triplet format, 
>> shouldn't this be 'powerpc-cell-unknown-linux-gnu'?  Cell is an 
>> architectural variant of power, not a systems vendor, right?
> 
> I'll let Mark comment on this, since it was his suggestion.  I think
> this is one of the cases where the meaning of "system" as the middle
> triplet entry is somewhat flexible.  :)

There's definitely a bikeshed in here...

The GNU way is that there are "canonical" triplets and then
non-canonical abbreviations.  The canonical format is $cpu-$vendor-$os,
so "sparc-sun-solaris2.8" if your system is built by Sun, and
"sparc-acme-solaris2.8" if your system is built by Acme, but contains a
SPARC, and is running Sun's operating system.  The world isn't always
this simple, and very little software pays attention to the $vendor value.

For Sourcery G++, we generally elide $system, and use a non-canonical
$cpu-$os format, which is equivalent to $cpu-unknown-$os.  So, for
example, "powerpc-eabi" is the target triplet for our Power EABI
toolchains, even though "powerpc-unknown-eabi" is the canonical triplet.
 Putting "unknown" into all our file names makes things any easier for
users -- and it just looks like we don't know things. :-)

The way GNU software is supposed to work is that you take the triplet
provided by the user and then run it through config.sub to get a
canonnical name.  Then, you make all your substantive decisions
(optimization, what functionality to include, tec.) based on the
canonical name, so that whether the user wrote "powerpc-eabi" or
"powerpc-unknown-eabi" makes no difference.  AC_CANONICAL_HOST is the
autoconf macro that canoicalizes --host=... for you.

I guess Joseph is right that the "-" in "powerpc-cell" might be a
hazard.  I think $cpu should definitely start with "powerpc", since
these are Power CPUs, and a lot of things expect to match powerpc*-*-*.
 It looks like GCC expects you do to "--target=powerpc-eabi" (or
whatever) and then ad "--with-cpu=cell" to say that the default CPU is a
Cell.

So, we could add --with-cpu, and then turn on the Cell bits only if the
CPU specified is Cell.  That would also give us a mechanism for things
like --with-cpu=970 to say "optimize for a 970 CPU".  Of course, since
we're a library, most of those decisions can be made with "#ifdef
__970__" style checks -- but perhaps not all.  (Or, we could jut have
--enable-cell, which is less general, but perhaps simpler.)

So, concretely, here is my revised recommendation:

1. Ensure that our configure scripts are looking at the canonical value
of $host, not the non-canonical $host_alias.

2. If reasonably convenient, add --with-cpu=..., and determine that we
are using Cell iff (a) $host_cpu matches powerpc*, and (b) $with_cpu
matches cell*.  (The *s allow people to add version information.)

3. If that's not convenient, recommend "powerpccell-linux-gnu" as the
host triplet for Cell GNU/Linux and then determine that we are using
Cell iff $host_cpu matches powerpccell*.

> P.S.: Mark, could you also comment on whether MCOE should get
> powerpc-mercury-mcoe or powerpc-unknown-mcoe?  I'm not very certain
> about that one at all.

Here, I think "powerpc-mcoe" is the obvious choice.  We don't care who
made the hardware.  Again, if we're using the canonical triplet
correctly, we should however match $host against powerpc*-*-mcoe* (which
means "any version of PowerPC, any system vendor, and any version of MCOE").

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713