Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!necntc!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.arch
Subject: Cache lookahead
Message-ID: <2769@mmintl.UUCP>
Date: 17 Mar 88 15:09:55 GMT
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Ashton-Tate Corporation, East Hartford Development Center
Lines: 27
Keywords: caching  RISC


This isn't a new idea, but I've never seen it discussed in a RISC context,
and it seems to have some unique advantages there.

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 reason this seems particularly attractive in RISC is that you often have
unused instruction slots anyhow, waiting for latency.  This seems like a
natural thing to fill such a slot with.

Of course, a sophisticated compiler is needed to take proper advantage of
this.  In the case of data, it may make more sense to just load it into a
register instead of merely "referencing" it, but this doesn't apply to code.
(And not even to data, sometimes.  If the access to the data is going to be
as an array reference in a loop, preloading the first few elements into
registers doesn't really help.)

Has anyone done anything like this?  Any idea what the costs are, and how
they compare to the benefits?
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108