Followup on ARM Minisummit at 2011 LPC
jcm at redhat.com
Thu Oct 6 18:41:19 UTC 2011
On Thu, 2011-10-06 at 15:20 -0300, Paulo César Pereira de Andrade wrote:
> Em 6 de outubro de 2011 14:38, Jon Masters <jcm at redhat.com> escreveu:
> > On Tue, 2011-10-04 at 00:41 -0300, Paulo César Pereira de Andrade wrote:
> >> For now I have been only considering gcc as compiler
> > I think, realistically, so have we. But I'm open to rethinking that.
> The problem is that this compiler apparently only offers two options,
> softfp (not softfp calling convention) by generating code without fpu
> support, and hardfp that only supports float arguments on float
> registers. IMO, the hardfp abi is not something for a distribution,
> but for a "closed" (not necessarily closed source) image, where
> the exact hardware is known before hand, and from Linux pretty
> much only the kernel and a few packages are used.
Yup. We disagree :)
I believe incompatible ABI changes are painful, but occasionally (very
occasionally, and with some planning, co-ordination, justification, and
a planned execution) can be necessary. The hard float ABI brings enough
benefits that the various distributions are standardizing on it for v7.
I would hope that we can all get behind this and treat v7 as a new
architecture rather than simply an iteration, but I understand if you
don't want to do that. Having said that, we do want to do that :)
> >> and the link in
> >> infocenter.arm.com appears to suggest that the mapping, to have an
> >> armv7 distro capable of running existing armv5 or older software, would be:
> >> gcc -mfloat-abi=softfp -mfpu=vfpv3-d16 -> tcc /hardfp /nofpregargs
> >> possibly replacing vfpv3-d16 with neon
> >> but the problem is, the tcc (arm C compiler!?) calls softfp what gcc
> >> calls -mfloat-abi=soft, but "now" only supports hardp with what gcc
> >> calls -mfloat-abi=hard calling convention.
> > So, it's true that we're basically saying as far as we believe Linux
> > distributions go in the ARMv7 timeframe, we assume hardfloat and will
> > all be using the newer ABI. Is that what you meant?
> Absolutely not agreeing :-) I have spent some time packaging, and
> got by myself over 3k Mandriva packages built for softfp, but it is mostly
> for "clearing the path", and knowing what is ahead; the same way
> I did go down all the way cross compiling several bootstraps, and starting
> building rpm, and then a few rpms for all toolchain setups.
I understand that you want a forward upgrade path from v5/v6 onwards. If
you have a substantive userbase, it might make sense to do "softfp" v7.
In our case, we consider it a better use of our (limited) resources to
keep a separate v5 build of Fedora around for those on older systems and
to build a new v7 version of the distribution for future use. It might
be nice to support both ABIs at the same time, but we don't right now.
As far as I know, the vast majority of us are doing hard float on v7. I
would like to know who else is in your position, so we can work together
to make the experience reasonably good for everyone. You're not the only
one doing something different. I just noticed, for example, that Sun's
Java bits claim to be "hard float" but they think that means VFPv2 :(
(can we *please* make a collective mental note that we won't take silly
terms like "hard float" in the future unless it's abundantly clear these
won't be repurposed later on? Hard float should mean precisely one
thing. If that is not trusted to be the case, we need a new term).
> One of the major problems I am seeing on this packaging work is
> because I did choose thumb2 (space saving and compatibility are worth it),
> so far I did either fetch linaro patches, tweak options, add -marm to
> CFLAGS and CXXFLAGS, etc, as most packages around expect
> arm instruction set, and few handle thumb2. There were a few other
> tricks, like some (very uncommon) code expecting "char" to be
> always "signed".
Fortunately, you can switch in and out, even on a per-package basis.
> Hardfp abi adds a completely new set of incompatibility in the field,
> that should affect asm in different places, break pretty much any
> jit/ffi around, does not run armv5 or earlier binaries, and all to have
> what? Like 3% (with luck) increase in performance in fpu intensive
> applications, while almost everything else has no benefits. From my
> understanding, it was wrong from start, and most likely caused by
> comparing apples to oranges, err, software float vs hardware float,
> probably also the software float one not using armv6 instructions,
> not "softfp abi" vs "hardfp abi".
I understand what you're saying. The view on our end was that this was
effectively a new architecture we could target so we would treat it as
such, and in so doing we might as well move to the newer ABI if we're
not intending v7 to be backward compatible with v5.
More information about the cross-distro