On Fri, Feb 04, 2005 at 03:19:49PM +0000, Dominic Sweetman wrote: > 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. I had dark memory of some el cheapo CPU having 4k caches. > 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. Linux computes the necessary alignment on the fly. The method used is not strictly correct because as you say it should account for possible I-cache aliases also. Seems it's cache day again today ;-) Ralf
