About arm choice of toolchain options
Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andrade at gmail.com
Tue Oct 18 15:43:39 UTC 2011
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
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.
> Loïc Minier
More information about the cross-distro