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. p.
