[fedora-arm] armv7hl requirements

[Gordan Bobic]

Jon Masters wrote:
> On Thu, 2011-05-05 at 22:36 -0500, Matt Domsch wrote:
>> On Wed, May 04, 2011 at 01:46:06PM -0500, Jon Masters wrote:
> 
>>> I'd like to kick off a discussion about flags for ARMv7. My proposal
>>> here is that we treat v7hl as an entirely different architecture, and
>>> don't try any multi-arch kind of hacks (there isn't the established user
>>> base for Fedora ARM to justify doing any of those things at the moment).
>>>
>>> Things I think we should consider as a minimum:
>>>
>>> *). Little endian (obviously, but worth stating) (l)
>>> *). Cortex-A8 or higher fully compliant core(s)
>> Is there a measureable difference in code optimized for A8 vs A9 when
>> running on A9?  If so, my inclination would be to build for the future
>> - A9.  It's not like A9 hardware is hard to come by these days.
> 
> There's a difference in performance at the microarchitecture level
> between Cortex A8/A9 and A15, but AFAIK not much between A8/A9. I spoke
> with some friends from ARM the other evening about this and I'll
> followup on the subject of tuning at the LDS event next week.
> 
> Anyway, for now I'm inclined to optimize for the future. We have a clean
> slate, and you know I'm all about portability and compatibility, but not
> if there's nothing already out there to worry about ;)

How important do we deem optimal operation on Efika and Beagleboard?

> We should make
> sure whatever we do that we're sane on A15 when it comes out. And I am
> inclined to realize the value of not harming support for Tegra, so that
> (in my mind) seals the deal with regard to VFP-D16 vs. D32.

Is there an ABI change required when going from A8/A9 to A15 to get most 
of the benefit from it, like there is between softfp and hardfp? If 
there isn't, I'm not sure it's worth worrying too much about. Target the 
most basic platform and have optimized packages for things that benefit 
from it most.

>>> *). ARM VFP3 hardware floating point (h)
>>> *). ARM NEON Architecture
>> If libraries using NEON can detect NEON-capable CPUs and switch to
>> using those functions, all the better.  Unfortunately, not all
>> A9 products include NEON, but then again, not all apps can make use of
>> NEON SIMD instructions anyhow.
> 
> Yea. I like the SSE analogy. If you see my followup emails later in the
> thread you'll see we decided that it wasn't worth requiring NEON and
> instead use the hwcaps and similar mechanisms to pull in the libraries
> as necessary. Worst case, we do a few optimized libraries one can
> optionally install, I guess similar to how x86 did i686 glibc.

Persactly. :)

> btw, I managed to unplug myself (well, physically re-located to a
> Starbucks and was only marginally distracted by IRC/email on my phone)
> for long enough earlier to read all of the AAPCS, relevant IEEE 754 and
> so forth, so I now feel that I have a good enough understanding of how
> the ABI is actually implemented. Think of aapcs-vfp as more of what they
> intended, and the non hardfp "base" standard as just an accepting the
> reality that VFP wasn't always present historically.
> 
> If you read how VFPv3 actually implements its registers, you'll see that
> the extra 16 (for D32) really are totally separate anyway as far as the
> ABI is concerned, so I remain unconvinced we lose a lot by being D16.

Can you clarify that? Does that mean that a we can have a D16 distro 
with D32 kernel/glibc?

Gordan