[fedora-arm] Support for ARMv7, hardware math

[Peter Robinson]

On Sat, Nov 27, 2010 at 5:16 PM, Chris Tyler <chris at 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.php

> 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