Re: armelfp: new architecture name for an armel variant
- To: Konstantinos Margaritis <firstname.lastname@example.org>
- Cc: Paul Brook <email@example.com>, firstname.lastname@example.org, Hector Oron <email@example.com>, firstname.lastname@example.org, Matt Sealey <email@example.com>
- Subject: Re: armelfp: new architecture name for an armel variant
- From: Guillem Jover <firstname.lastname@example.org>
- Date: Thu, 8 Jul 2010 13:06:58 +0200
- Message-id: <20100708110658.GA20823@gaara.hadrons.org>
- Mail-followup-to: Konstantinos Margaritis <email@example.com>, Paul Brook <firstname.lastname@example.org>, email@example.com, Hector Oron <firstname.lastname@example.org>, email@example.com, Matt Sealey <firstname.lastname@example.org>
- In-reply-to: <email@example.com>
- References: <AANLkTimoAsV_lxMTplp3aQv9vDM5Gx-31tU7pqnI6kfirstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
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
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.