[RFC] Add and armv7hf TARGET_ARCH

Wed Oct 8 17:47:15 UTC 2014

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 at 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 at 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 at 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 at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.