[RFC] Add and armv7hf TARGET_ARCH

Andrew Turner andrew at fubar.geek.nz
Mon Oct 6 21:41:32 UTC 2014


On Mon, 6 Oct 2014 10:30:45 -0700
John-Mark Gurney <jmg at funkthat.com> wrote:

> Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 +0100:
> > I'm interested in peoples opinion on creating a new TARGET_ARCH to
> > target ARMv7 SoCs. This will target all the current Cortex-A chips
> > we support but not the Raspberry Pi. My intention with this is to
> > have it become the tier 1 arm platform.
> > 
> > This platform will support 32-bit Cortex-A based SoCs with a VFP
> > unit. As it would be targeting ARMv7 we could look at supporting
> > Thumb-2.
> > 
> > As the VFP unit is optional and future SoCs without it will only be
> > supported by the armv6 TARGET_ARCH, however I would expect almost
> > all ARMv7 designs to include it.
> 
> So, what are the specific pros of having a new arch?  I see you talk
> about Thumb-2 support, but are there other advantages?  Will we get
> significant performance boosts?  What?

We would get a significant speed improvement for anything that uses
floating-point. I haven't done extensive tests, but Ian was getting
around 30x-34x improvement by using the vfp on one benchmark [1]. I've
seen a sight improvement of around 3-5 MFlops on his numbers on my
board.

I expect there to be a slight performance improvement from being able
to use the newer ARMv7 instructions, however this will be less
pronounced than the above floating-point improvement.

There are also a number of NEON optimised libc functions we could make
use of, for example [2]. While we may be able to use them on armv6 it
becomes simpler if we can assume we have a NEON unit.

> Also, what impact will this have on trying to get binary packages
> for other arm archs?  i.e. will this significantly take away
> resources? If we do this split, why would we want to build binary
> packages for RPI?

This would depend on how we expect to build them. If the packages are
cross built it would mean having two machines to build packages on
rather than one. If we have native package building I could see
managing two clusters could be difficult.

Andrew

[1]
https://lists.freebsd.org/pipermail/freebsd-arm/2014-February/007555.html
[2]
https://android.googlesource.com/platform/bionic/+/master/libc/arch-arm/bionic/memcpy.S


More information about the freebsd-arm mailing list