> From: arm-bounces(a)lists.fedoraproject.org [mailto:arm-
> bounces(a)lists.fedoraproject.org] On Behalf Of Jon Masters
> Sent: 06 May 2011 05:52
> To: Matt Domsch
> Cc: arm(a)lists.fedoraproject.org
> Subject: Re: [fedora-arm] armv7hl requirements
>
> 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.
Using ARMv7 VFP-D16 as baseline would be best. In terms of platforms, there
are now enough A9 based platforms to use this as default build target with
Fedora.
>
> > > *). 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.
Using hwcaps mechanism should enable you to pull in the right optimized
libraries for NEON.
Regards,
Philippe