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 ;) 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.
> *). 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.
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.
Jon.