Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!mips!himel
From: himel@mips.COM (Mark I. Himelstein)
Newsgroups: comp.arch
Subject: Re: Cache lookahead
Message-ID: <1902@gumby.mips.COM>
Date: 19 Mar 88 16:44:21 GMT
References: <2769@mmintl.UUCP>
Reply-To: himel@gumby.UUCP (Mark I. Himelstein)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 29
Keywords: caching  RISC

In article <2769@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
>The idea is that in a cached machine, the software often knows what it is
>going to be doing next.  If access to memory is not already your critical
>path, you can have instructions which reference a memory location, either
>code or data, but don't do anything with it.  Then, when the program gets
>around to looking at it, it is already in cache.

The MIPS M500/M800/M1000 has physical caches fronting slow memory (otherwise
why have the caches :-). We have a max of 8k 32 bit words of data cache and the
same for instruction cache. Our caches are a single line wide.

Some factors I'd be concerned with regarding this suggestion:
	- increasing the number of collisions within the process
		by adding memory accesses before their time.
	- increasing the inter-process cache collision rate when every
		switch entails changing more cache entries.
	- dirtying a cache page with respect to a memory page when
		you don't need to. If you reuse the memory page before
		you actually use it, the operating system will have to clean
		the cache.

(by collision I mean two memory references that use the same cache entry)

Wider cache lines could make the above factors worse. A very very good
compiler might be able to minimize the first factor but not the last two.

-- 
-Mark I. Himelsteing DISCLAIMER: I speak only for myself.
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!himel,   DDD:408-720-1700, x251
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086