Date: Mon, 6 Oct 2014 21:24:30 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Andrew Turner <andrew@fubar.geek.nz> Cc: freebsd-arm@freebsd.org Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141007042430.GH1852@funkthat.com> In-Reply-To: <20141006224124.494267e0@bender.lan> References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Turner wrote this message on Mon, Oct 06, 2014 at 22:41 +0100: > On Mon, 6 Oct 2014 10:30:45 -0700 > John-Mark Gurney <jmg@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. Don't we already have armv6hf for hardware float? What is the difference between armv6hf and armv7hf? or is this 30x-34x improvement over armv6hf? > > 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 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141007042430.GH1852>