Hi,
In the past few days I made some changes to djdelorie's bootstrap scripts to adapt it to mandriva, so, I believe I should at least give some feeback :-)
I have built two chroots on two panda boards, one with hardfp that should match current fedora, and another using --with-float=softfp, as at least for now I think it would be wiser for me, and available resources to be able to use a large amount of armv5 packages made by Matthew Dawkins, for Unity Linux.
Currently I am connecting to remote panda boards at jbj.org, so, Jeff is providing the infrastructure (currently I do not have access to armv7 hardware). The boards are running:
Linux panda3.jbj.org 2.6.38.8-32.01.fc13.armv7l.omap #1 SMP PREEMPT Tue Jun 14 22:12:54 EDT 2011 armv7l armv7l armv7l GNU/Linux [root@panda3 /]# cat /etc/fedora-release Fedora release 13 (Goddard)
So, for example (and sorry for long email) in fedora, and my other bootstrap chroot, with objdump I see the pattern: 00008b68 <__ieee754_atan2>: 8b68: e3a01000 mov r1, #0 8b6c: e3471ff0 movt r1, #32752 ; 0x7ff0 8b70: ec532b11 vmov r2, r3, d1 8b74: e3a00000 mov r0, #0 8b78: e0031001 and r1, r3, r1 8b7c: e3470ff0 movt r0, #32752 ; 0x7ff0 8b80: e1510000 cmp r1, r0 8b84: e1a0c003 mov ip, r3 8b88: e92d0030 push {r4, r5} 8b8c: ed2d8b10 vpush {d8-d15} 8b90: e1a05002 mov r5, r2 8b94: e24dd028 sub sp, sp, #40 ; 0x28 8b98: eeb08b41 vmov.f64 d8, d1 8b9c: eeb09b40 vmov.f64 d9, d0 8ba0: 0a000023 beq 8c34 <__ieee754_atan2+0xcc>
arguments in d0, d1
And in the alternate build I see the pattern:
00008d30 <__ieee754_atan2>: 8d30: e3a0c000 mov ip, #0 8d34: e347cff0 movt ip, #32752 ; 0x7ff0 8d38: e92d4030 push {r4, r5, lr} 8d3c: ed2d8b10 vpush {d8-d15} 8d40: e3a05000 mov r5, #0 8d44: ec432b18 vmov d8, r2, r3 8d48: e3475ff0 movt r5, #32752 ; 0x7ff0 8d4c: e003c00c and ip, r3, ip 8d50: e15c0005 cmp ip, r5 8d54: e24dd02c sub sp, sp, #44 ; 0x2c 8d58: e1a04003 mov r4, r3 8d5c: ec410b19 vmov d9, r0, r1 8d60: e1a05002 mov r5, r2 8d64: 0a000022 beq 8df4 <__ieee754_atan2+0xc4>
arguments in r0,r1,r2,r3
I did not do any performance measures so far, so forgive me if the extra "vmov d#, r#,r#" or "vmov r#,r#, d#" is too costly, but I think it should be worth the compatibility with rpms for armv5 or earlier. It should have been already discussed at fedora, but I really do not know the real reason :-)
Also, as I am still in very early stages, and doing experiments, so far I am using only the cross compiled gcc, i.e.:
bash-4.2# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: /home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure --prefix=/usr --build=i586-mandriva-linux-gnu --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix --disable-libssp --disable-libmudflap Thread model: posix gcc version 4.6.1 20110722 (Mandriva) (GCC)
But have already rebuilt some of the "bootstrap" mandriva packages, rpm5, etc, as well as have packages built for armv5 installed. This way, rebuilding for armv7 is an "optimization", and have something to start with...
Thanks, Paulo
On Sat, 2011-07-30 at 00:37 -0300, Paulo César Pereira de Andrade wrote:
I did not do any performance measures so far, so forgive me if the extra "vmov d#, r#,r#" or "vmov r#,r#, d#" is too costly, but I think it should be worth the compatibility with rpms for armv5 or earlier. It should have been already discussed at fedora, but I really do not know the real reason :-)
But have already rebuilt some of the "bootstrap" mandriva packages, rpm5, etc, as well as have packages built for armv5 installed. This way, rebuilding for armv7 is an "optimization", and have something to start with...
If you're arguing that one could build support for soft float and have hard float as an option, I must point out that the reason we're doing things as we are is that the hard floating point requirement forms part of an ABI switch that we are making concurrent with the bringup. The newer ABI is intentionally incompatible, but can be thought of as an architecture revision since we're requiring v7+ at the same time.
We don't have years of ARM backward compatibility to worry about, so now is the time to move to the newer ABI, which everyone else is moving to at the same time. Once we're super successful and famous, and a primary architecture with millions of users, then we can worry about any changes we might make in the future. At this stage Fedora ARM doesn't have the history to justify putting off making a switch, and we'll keep a v5 build of the packages around for those who want that longer term.
Jon.
Em 30 de julho de 2011 02:48, Jon Masters jcm@redhat.com escreveu:
On Sat, 2011-07-30 at 00:37 -0300, Paulo César Pereira de Andrade wrote:
I did not do any performance measures so far, so forgive me if the extra "vmov d#, r#,r#" or "vmov r#,r#, d#" is too costly, but I think it should be worth the compatibility with rpms for armv5 or earlier. It should have been already discussed at fedora, but I really do not know the real reason :-)
But have already rebuilt some of the "bootstrap" mandriva packages, rpm5, etc, as well as have packages built for armv5 installed. This way, rebuilding for armv7 is an "optimization", and have something to start with...
If you're arguing that one could build support for soft float and have hard float as an option, I must point out that the reason we're doing things as we are is that the hard floating point requirement forms part of an ABI switch that we are making concurrent with the bringup. The
I am saying that I find the softfp option more appealing *if* not also switching to thumb instruction set. From gcc.info: "`softfp' allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions". This allows armv5 packages, to work because they use the same calling convention, and the abi difference is only that it now pass/return values in vfp registers, and, to conform to abi, should use only two registers anyway.
newer ABI is intentionally incompatible, but can be thought of as an architecture revision since we're requiring v7+ at the same time.
We don't have years of ARM backward compatibility to worry about, so now is the time to move to the newer ABI, which everyone else is moving to at the same time. Once we're super successful and famous, and a primary architecture with millions of users, then we can worry about any changes we might make in the future. At this stage Fedora ARM doesn't have the history to justify putting off making a switch, and we'll keep a v5 build of the packages around for those who want that longer term.
Jon.
Paulo
-
Jon Masters -
Paulo César Pereira de Andrade