Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On 7/15/10, Loïc Minier <lool@dooz.org> wrote:
> armel can also use vfp instructions, so I personally find it confusing.
No it can't. Any binary that contains a vfp instruction will die with
SIGILL on any armv4t chip that has no vfp cpu, so cannot be used in
Debian armel.
As far as the ABI is concerned, the new roposed one specifically uses
VFP registers to pass FP arguments, so the new arch would require a
VFP coprocessor.
> In any case, we're free to use the vendor field, but that shouldn't be
> used in upstream software.
+1, if we must have a new GNU name.
> arm-hardfloat-linux-gnueabi
Would probably work with most existing build scripts
> arm-linux-gnueabi_hf
Would probably require modifying again every build script that has
already been modified to recognize -gnueabi - to make it do the same
as it would have done for -gnueabi, which seems like creating
pointless extra work for other people...
> (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)
You must have misunderstood what Richard said.
I use Maverick hardlfoat in EABI and provide a repository of Maverick
hardfloat debian packages for Debian armel. It all works fine.
You're right that FPA hardfloat won't work with it, because the ABI
specifies FP storage format and FPA's storage format is different
(45670123 mixed-endian).
However, since the new ABI would mandate passing floating point values
in VFP registers, that knocks any other incompatible FPUs out of the
water anyway.
As regards what ARM Ltd want: to stamp their cortex trademark on a
Debian port and to get Debian to optimise an architecture for (and
mandate the use of) the very latest version of their product line,
this is not necessarily in the best interests of the users or the
developers of Debian. THe users would be best served by a supporting
the least-common-denominator VFP instruction set that runs on as many
chips as possible, which seems to mean a baseline VFP with 16
registers.
I still doubt that the disruption and extra work for the community of
Debian package maintainers, and the lower quality of the resulting
archive, is worth the small increment in speed that is promised. I
hope
M
Reply to: