[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: