Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

[Loïc Minier <lool@dooz.org>]

On Wed, Jul 14, 2010, Hector Oron wrote:
> Genesi have recommended 'cortex' as Debian architecture name and
> 'arm-hardfloat-linux-gnueabi' as triplet. This has been in fact
> approved and endorsed -and actually encouraged- by ARM itself, they
> really liked the idea of having a debian-cortex port.

 cortex as the port name sounds very wrong, as others have commented
 already:
 * some CPUs we explicitly targe t(by configuring for vfpv3-d16) aren't
   cortex (they don't instantiate the Cortex-A8 gates on the silicon,
   but a custom design which is compatible to the armv7 architecture)
 * (minor) what if ARM releases a "speedex" which is armv7 or armv7
   compatible?

 "armvfp" is also being put forward; while this seems to make sense,
 armel can also use vfp instructions, so I personally find it confusing.

 If we take a step back and ask ourselves why we're doing this new port,
 it's because of a new ABI using hard-float across library calls.  Hence
 armhf.  It turns out that we also take an opinionated view that armv7
 and vfpv3-d16 are modern choices for the port, so we could indeed use
 armv7hf or armhfvfp to reflect this, but it's ugly.


 I think there was consensus that {arm,armel}{hf,fp} were reasonnable
 names; I don't care too much across these, but please avoid armv7, vfp,
 cortex in the port name; it's first about a new ABI.


 Concerning the triplet choice, I'd highly recommend reading this
 upstream thread:
    http://gcc.gnu.org/ml/gcc/2010-07/threads.html#00179
 Upstream is basically split on whether a new triplet is needed or not.
 In any case, we're free to use the vendor field, but that shouldn't be
 used in upstream software.  Upstream software should ignore the vendor
 field and detect whether the current ABI is hard-float or soft-float.
 I think changing the triplet is easier than changing the port name, so
 I wouldn't be too worried if the port were to start with
 arm-hardfloat-linux-gnueabi and change to arm-linux-gnueabi_hf or so
 later.

 (BTW in the thread Richard Earnshaw makes the point that FPA isn't
 leagel in EABI and that maverick is incompatible with it, so I think
 this is another reason not to have "vfp" in our new port's name)

-- 
Loïc Minier