Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On Thu, Jul 15, 2010, Martin Guy wrote:
> 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.
Yes, it will die /on chips without a VFP/, but Ubuntu has an armel port
with vfp turned on by default, and Debian has some packages which
provided alternate version of libraries which are optimized for a
different FPU...
> 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.
Yes, armhf requires a VFP, but armel allows using the VFP, so VFP is
not very clear.
> > (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.
Perhaps your implementation is not officially supported in the EABI
then? Please discuss this with Richard though; I know next to nothing
about the EABI specification or about maverick fpus.
> As regards what ARM Ltd want:
Are you speaking on behalf of ARM?
> 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.
The plan is to configure with vfpv3-d16 anyway, and there is no plan to
get rid of the armel port...
--
Loïc Minier
Reply to: