[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, 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: