More ARM binutils fuckage

Lennert Buytenhek buytenh@wantstofly.org
Sun Dec 24 14:59:00 GMT 2006


On Sun, Dec 24, 2006 at 09:46:10AM -0500, Jonathan S. Shapiro wrote:

> If there is a way for the ARM architecture to get cache consistency
> wrong, it is always best to assume that ARM did that.

ARM so far didn't try to have x86-style cache coherency.  Part of the
reason for this I suspect to be that they've always licensed their MMUs
as an add-on to the CPU core, and so it was easier to separate the MMU
from the rest of the CPU core by keeping the dcache and icache virtual
(pure speculation, but it makes the most sense to me that way.)

The ARMv6 VMSA specifies an optional 'Shared' page table bit, which is
supposed to provide cache coherency in an implementation-defined way.

The newer xscale cores (xsc3) implement this bit (albeit in a different
location in the page table entry, yay!) using an optional PIPT L2 cache,
which can snoop the bus and support cache coherency (DMA coherency) that
way.  (Iff your peripheral is connected to the same on-chip bus as your
CPU, that is -- in the new xsc3-based Intel IOP dual core ARM processors,
for example, the two CPU cores are connected to the same bus but the PCI
unit is connected to a different bus.)

I've heard that L1 caches in ARM (as in, ARM the company) SMP systems
are actually PIPT.  I hope they're finally abandoning the idea that
virtual caches make sense in any way.

The self-modifying code case (i.e. writing via the dcache to a line
that might be present in the icache) is still not addressed.  And I
don't expect this to change -- whereas x86 spends a lot of effort on
trying to get this right, other architectures just don't bother, and it
works fine for them.

--
For unsubscribe information see http://sourceware.org/lists.html#faq



More information about the crossgcc mailing list