On Thu, Oct 06, 2011 at 03:20:16PM -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.
fyi, I found that this page contains a pretty good explanation of why we ended up where we are (at least from Debian's POV): http://wiki.debian.org/ArmHardFloatPort
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.
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".
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".
Jon and I have both been talking to Mats and Jeff about LSB already, but things have gone a little quiet while we've been concentrating on bringup in the last few months. They would definitely be the right people to work with going forwards...
So...Adam, we need to sync up on this. I would like to have made a little progress by the time we get to Connect next month.
Jon.
Paulo
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro