Date: Wed, 8 Oct 2014 19:46:42 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@freebsd.org Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141008174642.GA19893@cicely7.cicely.de> In-Reply-To: <66C40BCC-C829-4540-A19E-C9EFA64191F6@bsdimp.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> <66C40BCC-C829-4540-A19E-C9EFA64191F6@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 08, 2014 at 09:28:03AM -0600, Warner Losh wrote: > > 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. The BBB and Wandboard works much better for me. Granted: there is HDMI support for the RPi, but then the pro section ends. Last time I tried the RPi is still was picky about the SD cards used. And it had problems with my test-LCD resolution not being a plain HDMI resolution, which Linux hadn't. I will surely retry it in a few weeks and I also have a few B+ boards to test. Nevertheless I also have some Hummingboards to test and I like the iMX6 way more. But having packages for the RPi a requirement for mainstream users, since it is a very popular platform. > > 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. My understanding is that NEON shouldn't be a problem as CPU_TYPE. But the big winner is the different function call semantic for floatingpoint. > >> 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). -- B.Walter <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141008174642.GA19893>