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 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715145609.ga3...@bee.dooz.org
