Re: Proposal - take 2

From: Phil Blundell <pb.a.t.nexus.co.uk>
Date: Thu Feb 05 2004 - 12:03:23 EST

on Thu, Feb 05, 2004 at 05:39:44PM +0100, Michael Opdenacker wrote:
> h2200 support is already declared in the standard ipaqpxa config. This
> means we can already use the same kernel package as other devices,
> provided h2200 support was enable in it.

Ah, right, excellent.

> You mean that compiling for pxa too is more work, sometimes not worth
> the effort, for the one who does the extra compile job, right? Are there
> other costs?

Well, there's also an ongoing maintenance overhead, in that we would
then have two binary packages that need to be updated rather than just
one. I can imagine that all kinds of user confusion would result if
different architectures were using different versions of the same
package.

For most software, the improvement from just flipping the -march=armv5te
switch is likely to be minimal or nonexistent. The new stuff falls into
four main categories:

 - the El Segundo dsp extension, which isn't supported in gcc and would
only be of benefit for fairly specialised algorithms anyway.

 - the CLZ instruction, which is only generated in response to
__builtin_clz, and seldom used in performance-critical code.

 - the PLD instruction, which is only generated under
-fprefetch-loop-arrays or in response to __builtin_prefetch. This can
be a significant performance gain in some applications, but can also be
a loss if used indiscriminately.

 - Thumb, which generally gives smaller code size at the cost of lower
performance. This can be a win in some cases, but doesn't work very
well at present when shared libraries are involved.

So, there's the potential for gains (especially with PLD) but, generally
speaking, realizing them will involve a little more effort than just
recompiling with different CFLAGS. This is probably only going to be
worthwhile for a limited set of software; either shared libraries that
are used by everything (libc, libgtk and so on), or highly
performance-critical code (video and audio codecs). Recompiling random
applications for XScale is unlikely to be all that rewarding.

p.
Received on Thu Feb 05 17:03:24 2004

This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:41:46 EDT