Hi! On Tue, 2010-07-06 at 21:07:10 +0300, Konstantinos Margaritis wrote: > On Tuesday 06 July 2010 20:45:33 Paul Brook wrote: > > Debian is pure soft-float (i.e. -mfloat-abi=soft). > > Right, all the more reason for a new flavour then :)
Actually, this only seems to me to indicate the option that Aurelien was mentioning (building few core packages with softfp) should be strongly considered instead of adding a whole new architecture, which didn't look had been properly explored from the initial mail? > > -mfloat-abi=soft and -mfloat-abi=softfp are binary compatible (objects and > > libraries can be freely mixed). Obviously softfp code will will only work > > on a CPU with an FPU, but that's not different to (say) armv5 v.s. armv6 > > or vfpv2 v.s. vfpv3. > > > > -mfloat-abi=hard is not compatible with either of the other -mfloat-abi > > options. > > Hm, true, my mistake. Still, now with A8 and A9 cores, software is > underoptimized even with softfp. Hence the request for a new flavour. :) Personally, before any further discussion I'd like to see some numbers with core libraries (libc, libgcc, libgmp, libatlas? etc) built with softfp, which eventually might be able to switch to use the hwcaps infrastructure in a similar way as how packages like libc6-i686 are handled. Adding a new (official) architecture variant is a huge overhead for everyone, it implies adding new porter boxes, patching packages (but hopefully not many) to handle the new arch, having someone handle the build daemons, porters to handle arch specific issues (which arguably should be minimal given the semblance with armel, but still), more mirror space, user confusion due to the incompatibility of the binaries that might run on the same hardware, and I'm probably forgetting others. The lpia is a great example of an architecture variant that was a mistake, and should haver never been created. If the arm porters decide afterall that they want something like armelfp anyway, then of course I'll be glad to add the architecture name to dpkg, but I'd first try to exhaust other alternatives with way less overhead. thanks, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
