On Sat, Nov 27, 2010 at 5:16 PM, Chris Tyler <chris(a)tylers.info> wrote:
So I've had a number of conversations with Dennis Gilmore and
folks from
other ARM disro ports about v7 support, and particularly with respect to
hardware math. (In addition, one of the Seneca students is currently
investigating v5 vs. v7 support in an attempt to figure out how much of
the Fedora universe needs to be recompiled for optimal benefit).
From my interpretation of the gcc notes on float it looks like the two
are mutually exclusive. From the notes "Note that the hard-float and
soft-float ABIs are not link-compatible; you must compile your entire
program with the same ABI, and link with a compatible set of
libraries. "
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
From some of the Linaro "next 6 months" tasks it looks more
like there
will be NEON optimised packages that can be added to ARMv7 packages as
opposed to ARMv7 added to 5tel.
https://wiki.linaro.org/Linaro-arm-hardfloat
Regarding hardfp, though, things are quite unclear. My understanding
of
soft/softfp/hardfp was initially wrong. As I understand it now:
- soft does all the math in software. Function values are passed in CPU
registers where appropriate.
- softfp enables the use of FPU instructions, but continues to pass
function arguments in CPU registers. This mode enables hardware
acceleration of math and interoperability with soft, at the cost of a
CPU->FPU register move in some cases.
- hardfp enables the use of FPU instructions, and function values are
passed in FPU registers where appropriate. This mode is incompatible
with soft and softfp, and cannot be used on CPUs that have an FPU.
According to gcc (docs + error messages), it is also incompatible with
CPUs that use a "vfp" math unit, such as OMAP3xxx CPUs (BeagleBoard) and
(I think) the CPU used in the XO1.75. I'm unclear on which hardware math
units it is compatible with.
My understanding is that all the ARMv7 chips have vfp3 but there's two
different versions (16 and 32) which means that all the A8 chips
should support that, and it seems on the A9 its optional.
http://www.arm.com/products/processors/technologies/vector-floating-point...
In terms of hardware support, I think we definitely want to continue
to
support armv5tel with software floating-point, since that's what is used
on many current Marvell CPUs, including those used in the
SheevaPlug/GuruPlug/OpenRD.
We most definitely need to support 5tel but it would also be good to
choose a ARMv7 level to support as well. I'm not sure if its worth
seeing what Linaro/MeeGo/Ubuntu/Debian support to try and be aligned
with them as it would no doubt help in terms of upstream bugs with
glibc/gcc etc
hardfp would break compatibility with all of the existing binary
packages, and hardfp can't be compiled by gcc for any of the CPUs I have
got my hands on so far.
It would seem that its a definite second repository like i686/x86-64
but it also seems that there's patches pending for gcc 4.5.1 so it
might a F-15 target unless we can get an updated gcc for F-14 but the
BeagleBoard and n900 should both support some version of hardfp
Thus, I recommend that we aim at armv7l softfp to support as an arch
alongside armv5tel.
Comments?
Peter