About arm choice of toolchain options

[Paulo César Pereira de Andrade]

2011/8/1 Loïc Minier <loic.minier at linaro.org>:
> On Sun, Jul 31, 2011, Paulo César Pereira de Andrade wrote:

  Hi, sorry for returning back to this discussion.

>>   If I understand correctly, neon will have better support for
>> simd instructions right?
>
>  NEON is effectively SIMD instructions, but not all modern SoCs have
>  NEON, e.g.  NVidia Tegra2 don't have NEON.  It's becoming common place
>  in recent SoCs though.
>
>>   Either way, I used two simple benchmarks to try to sell
>> myself the idea of breaking compatibility with armv5 or
>> older binaries, but still not convinced, but, as I said, we
>> should use whatever "The Industry" chooses :-)
>
>  Depends which industry though.  Yes, ARMv5 will be around for a while,
>  but high-end devices, phones, tablets etc. are designed around ARMv7.
>  Depends what your distro targets too; for instance Debian armel targets
>  ARMv4T+ while Ubuntu armel is based of the same sources but targets
>  ARMv7+ and uses Thumb2.
>
>>   I used for benchmark http://www.tux.org/~mayer/linux/bmark.html
>> and http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Why-ARMs-EABI-matters/
>> and also compared with my home computer (quad)core i5 x86_64,
>> and attached results...
>
>  You're likely not going to see much difference switching float ABI
>  alone with common benchmarks, because GCC is clever enough to use the
>  best possible ABI for non-public functions.  It's mostly visible when
>  you're crossing library calls with floating points.
>
>  You should however definitely see a difference between ARM mode and
>  Thumb-2 mode (which is ARMv6+ only IIRC), as the code is denser and
>  fits more easily in CPU cache.

  On simple tests it did not show much difference, but the space saving
is quite noticeable. Same for neon, but I believe neon would make more
of a difference on vectorized integer operations.

>  There were many discussions around this on the debian-arm list last
>  year; Konstantinos Margaritis collected benchmarks for hard-float which
>  should be linked from
>  http://wiki.debian.org/ArmHardFloatPort

  I did make an initial port of Mandriva using softfp, it has almost all
dependencies for a "proper" distro rebuild in place, e.g. most of gtk/gnome,
qt4/kde, but it is unofficial, and so far only have a qemu image, or can
unpack the image in a chroot; I have been using vnc in a ssh tunnel for
testing graphical applications...

  But now I am working on repeating the same steps in a hardfp
bootstrap, so that, theoretically, any binary for fedora hardfp should
just work, and hopefully, the same for linaro.

  What is the current state of hardfp toolchain? I ask because softfp,
what I earlier considered the most sane engineering option, just builds
and works using upstream binutils/gcc, but hardfp requires some
hacking; I have been using and building weekly LATEST-4.6 gcc
snapshots for quite some time.

>   HTH
> --
> Loïc Minier

Thanks,
Paulo