Em 6 de outubro de 2011 15:41, Jon Masters jcm@redhat.com escreveu:
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@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 :)
I understand that the arm ecosystem is not like x86; imagine if suddenly distros did choose to use regparm=n, sseregparm=n, well most distros already expect i686/sse, but do not use sse due to abi constraints.
I think the point here is the "bring enough benefits" that we are not agreeing. Personally, what I am afraid is that who will decide this is not distros, but companies providing binary blobs (e.g. video drivers). Talking again about x86 example, currently Mandriva Brasil makes several OEM images, and for most of them, besides x86_64, we need to make 32 bit images due to binary blobs.
About the abi, for most things it should be ok, but on the jit/ffi side, usually one should not expect any reliability with varargs functions, but printf is so cute :-) Problem is that the hardfp abi uses softfp abi to pass doubles as vararg function arguments.
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).
Lets call it Hardware Freedom :-)
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.
Unlike the abi :-)
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.
Jon.
Paulo