Date: Mon, 06 Oct 2014 16:05:38 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Andrew Turner <andrew@fubar.geek.nz> Cc: freebsd-arm@freebsd.org Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <1412633138.12052.180.camel@revolution.hippie.lan> 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
On Mon, 2014-10-06 at 22:41 +0100, Andrew Turner wrote: > 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. > The improvement from softfloat to softfp (hardware floating point with function-call arguments passed in integer registers) was huge. I would expect the improvement from softfp to full hardfloat to be a small increment on top of that. I have a vague memory of testing that and not seeing a dramatic difference, but I can't find any notes or test results. -- Ian > 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 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1412633138.12052.180.camel>