[RFC] Add and armv7hf TARGET_ARCH

[Ian Lepore]

On Mon, 2014-10-06 at 22:41 +0100, Andrew Turner wrote:
> 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.
> 

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"