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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_BBA02A9D-6D8E-4B80-950D-5F5D25EC6E44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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: >>=20 >>> 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: >>>>=20 >>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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? >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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? >>=20 >> 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. >=20 > 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? =46rom my understanding, NEON is common on > SoCs now, isn't it? The more I=92ve thought about it, the more we need to seriously consider = treating this as a MACHINE_CPUTYPE rather than a MACHINE_ARCH. Unless there=92s 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=92s no difference between the = current armv6hf and your proposed armv7hf except for allowing a few additional = instructions to be used. There=92s no calling differences, there=92s nothing apart from = using NEON (unless I=92ve 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. >>=20 >> 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. >=20 > 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... >=20 > So, do you envision armv7hf being the main Tier 1 arm platform? I think the separate MACHINE_ARCH isn=92t 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 --Apple-Mail=_BBA02A9D-6D8E-4B80-950D-5F5D25EC6E44 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----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----- --Apple-Mail=_BBA02A9D-6D8E-4B80-950D-5F5D25EC6E44--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66C40BCC-C829-4540-A19E-C9EFA64191F6>