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