linux-mips
[Top] [All Lists]

Re: c-r4k.c cleanup

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: c-r4k.c cleanup
From: Dominic Sweetman <dom@mips.com>
Date: Fri, 4 Feb 2005 15:19:49 +0000
Cc: Nigel Stephens <nigel@mips.com>, Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
In-reply-to: <20050204145803.GA5618@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050204.231254.74753794.anemo@mba.ocn.ne.jp> <4203890B.5030305@mips.com> <20050204145803.GA5618@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
Only some CPUs suffer from aliases.  A 4Kbyte direct-mapped cache must
be alias free, because all the virtual index bits are the same (being
in-page) as the physical address bits.  That's true but irrelvant,
since there aren't any 4Kbyte caches: but what's slightly less obvious
is that a 16Kbyte 4-way set-associative cache is also alias free.

24K's "AR" bit trick applies *only* to the D-cache, and only to a
32Kbyte cache.  (But then most alias problems are D-cache aliases, and
32Kbyte happens to be the most popular size for a 24K cache - so this
is a trick worth doing).

Note that I-cache aliases are not completely harmless; sometimes you
want to invalidate any I-cache copies of some data, and if it's
aliased you may miss some of them.  Shared libraries are generally
aligned to some large page-size multiple - so multiple text images are
usually the same colour, and don't matter.  You can get problems with
trampolines and stuff.

--
Dominic Sweetman
MIPS Technologies



<Prev in Thread] Current Thread [Next in Thread>