>> From: arm-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:arm- >> bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jon Masters >> Sent: 06 May 2011 05:52 >> To: Matt Domsch >> Cc: arm@xxxxxxxxxxxxxxxxxxxxxxx >> Subject: Re: 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
