[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian testing/unstable on RiscPC ?

On Wed, 2004-01-28 at 19:54, Peter Teichmann wrote:
> The only difference between v3 and v4 is the presence of the
> long multiply and ldrh/strh instruction. I admit that there 
> are applications that benefit greatly from these instructions, 
> but overall the performance benefit will not be noticable.

Yes, clearly it depends on your application mix.  Providing an
equivalent for "ldrsh" in ARMv3 requires something like seven
instructions and an extra register, so code quality is clearly going to
suffer if this happens frequently.  Long multiplies are a similar
story.  You're right that this can be addressed by building specially
optimised shared libraries, but this solution is quite
maintainer-effort-intensive and somewhat wasteful of space.

There's one other fringe benefit to ARMv4, namely that it has more
helpful semantics for unimplemented instructions in the extension
space.  Many of these opcodes will take the undefined instruction trap
from v4 onwards, rather than just quietly performing some bogus
operation as happened in v3.  So, it becomes feasible to provide
in-kernel emulation for, say, BX or the v5 instructions.  I'm not sure
if this is something that will really be interesting for Debian, but
it's worth bearing in mind.

> Especially, if one takes into account that, for typical Unix
> applications, the speed of ARM processors is limited by main 
> memory speed, because there is no L2 cache.

This is true up to a point, but of course the RiscPC is an extreme case
of this.  A more typical system nowadays would have a 200MHz or 400MHz
core with 100MHz SDRAM, so the imbalance between core performance and
memory bandwidth is much less.

> I believe it should not be too difficult to fix that bug in gcc for a person 
> who is involved in this!

No, indeed.  In fact, the bug is already fixed upstream, though the
patch hasn't yet been pulled into debian-gcc.

The bigger challenge would be to identify, recompile and binary NMU all
the affected packages, which is potentially a significant chunk of the
archive.  We don't necessarily have to do that now: we could just change
the compiler back, and hope that natural archive churn will mean that
most of the tainted binaries fade away before Sarge is released.


Reply to: