From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 22:05:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C9C09E for ; Mon, 6 Oct 2014 22:05:43 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD18B8 for ; Mon, 6 Oct 2014 22:05:42 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XbGPV-000KND-QP; Mon, 06 Oct 2014 22:05:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s96M5dwV029025; Mon, 6 Oct 2014 16:05:39 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ZGiI++o6dvzD3gne5WOn9 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [RFC] Add and armv7hf TARGET_ARCH From: Ian Lepore To: Andrew Turner In-Reply-To: <20141006224124.494267e0@bender.lan> References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Oct 2014 16:05:38 -0600 Message-ID: <1412633138.12052.180.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:05:43 -0000 On Mon, 2014-10-06 at 22:41 +0100, Andrew Turner wrote: > On Mon, 6 Oct 2014 10:30:45 -0700 > John-Mark Gurney 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"