Date: Wed, 8 Oct 2014 09:28:03 -0600 From: Warner Losh <imp@bsdimp.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-arm@freebsd.org Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <66C40BCC-C829-4540-A19E-C9EFA64191F6@bsdimp.com> In-Reply-To: <20141007234136.GS1852@funkthat.com> References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan> <20141007042430.GH1852@funkthat.com> <20141007094431.09600b56@bender.lan> <20141007234136.GS1852@funkthat.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Oct 7, 2014, at 5:41 PM, John-Mark Gurney <jmg@funkthat.com> wrote: > Andrew Turner wrote this message on Tue, Oct 07, 2014 at 09:44 +0100: >> On Mon, 6 Oct 2014 21:24:30 -0700 >> John-Mark Gurney <jmg@funkthat.com> wrote: >> >>> 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? >> >> My plan is to replace the armv6hf with armv7hf. The difference between >> the two is, on armv7hf we can assume newer floating-point instructions >> including the NEON SIMD instructions. > > Ahh, ok. this makes more sense then... If we really only loose the > RPI, I don't think that it's that big of a loss... Considering how > many other boards would get a boost.. But the RPi is arguably our best supported platform on ARM ATM. > So, the real move is switching to armv7hf is the new requirement that > NEON be present, correct? From my understanding, NEON is common on > SoCs now, isn't it? The more I’ve thought about it, the more we need to seriously consider treating this as a MACHINE_CPUTYPE rather than a MACHINE_ARCH. Unless there’s a really really compelling win from the NEON architecture, in general, we should consider doing this like we did i486 vs i686 for years on the i386 platform. Users can build for higher models, and use newer instructions on those models, but the base retained compatibility. There’s no difference between the current armv6hf and your proposed armv7hf except for allowing a few additional instructions to be used. There’s no calling differences, there’s nothing apart from using NEON (unless I’ve missed something). This seems completely analogous to the MMX instructions before. >> The performance improvement above was changing from the soft to softfp >> ABI. Softfp allows the compiler to generate vfp code, but will pass >> floating-point data between functions in the integer registers. >> >> It has been reported on some cores moving data between the vfp and arm >> registers can cause both to stall for at least 20 cycles [1]. While >> armv7hf doesn't remove the need to move between groups of registers >> completely it will reduce the need due to the calling convention. > > Yeh, sounds like it's good to move to armv7hf considering the number of > platforms... We could possibly leave armv6hf in the tree, but make > sure people realize that it's not a "supported" option... > > So, do you envision armv7hf being the main Tier 1 arm platform? I think the separate MACHINE_ARCH isn’t the way to go. I would support creating the proper CPUTYPE here. I might support the v7 variant being the default if there was a big enough win, since having the v6 variant default would let RPi folks get hard float by default (and I just checked: the RPi does support hard float, just not the latest NEON stuff v7 does). Coments? Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNVgDAAoJEGwc0Sh9sBEAKyYQANYMbQlissjIetK8jroaFTc/ sMDPvTAB0qfAf1wEjXMei5dFhjfpC99LfM0bijcOWheswvBGxlyyVIUfl2kYIm0J Dh8b7MiHTzGN5XVCsPzVSlbQuXjRYHx9ZEDDHuiaZMXWVv0cProXkmpwmoZ+c6cU mKQoSha3QtHahmgy+UoRkIWuYIYDo1f+5lOkGeJoQemDoNHqo00GcjPFxnseHo3S nVVueP4HLNqRLW53IC6aFZbojsabLR8OotJGea9diIPeY4Oz1axjlv4FIyB/f6Na PRde47cDhDnICALnYRnbm2IutAXQXKHX2uEVxjdUlmqLTnxh8fJerayyYOXa/tvE MQRygctECqlw6MIduejH6AsF2Y9zBTHaIOZFjRNedgZkxXk4daAdeyIsWP3OZg6R 2X1bFspWpiaw9zSa9A+9cUbE7CnPDEPhEpYN1vrMppQYvxoxnqqEakMXU1HZtFsz bWatQOxtVgnYuYq06Z16UHXec+i3yBGoScMO4r+BtfDNyZTAvhW6D3kmRafE+Rot wyOsHRYhLgEjXgT+fGZs/YH/rt9GqN8hs1fGXZ+wWkopRYBa0SdXGStP1MP7J5xG wbTqId1zbWeh8ehOOZkObScw/R90YpO6WKo21Z3Nn6XeN0K9vOVF47dTa4s/0OrA P52tTe9NFgOkTQodwtMf =mQU9 -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66C40BCC-C829-4540-A19E-C9EFA64191F6>