Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Thu, Jul 15, 2010 at 10:00:28AM +0200, Loïc Minier wrote:
> 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?
How is that different than i386 works on i686? The name is essentially
the minimum cpu that can run the code.
> "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)
Too many arm choices... Argh! :)
--
Len Sorensen
Reply to: