🚀 go-pugleaf

	Here's a (possibly crazy) idea for cache design.  The current EUD
(Example Under Debate) shows that caches just don't work for sequential
access, but we knew that already.  You can argue about how doing very wide
memory fetches will preload the cache for sequential accesses, but that's
certainly a second order effect.

	What if you segmented the virtual memory space (Oh no!  Not
segmented address spaces again!  Shades of Intel!) so that the top bit was
a hint to the cache on probably access patterns.  Variables which were
expected to hit the cache a lot (SUM and I in the EUD) would be put in the
"normal" part of the address space.  Variables which were expected to be
sequential access and thus never hit (VEC in the EUD) would be put in the
other half of the address space.  The cache would know to not bother doing
a tag match on this kind of access.  The advantages would be faster access
time (a memory fetch should be faster than a cache miss followed by a memory
fetch) but more important it wouldn't cause bogus cache flushes.

	As with every crazy idea, you can expand on this in all sorts of
ways.  You might use more than one high order bit to provide lots of
different sorts of hints to the cache.  You might want to be able to turn
the hinting on and off, or even make it programable.  Of course, every bell
and whistle adds cost and complexity, and reduces the chance that you will
use the fancy features well, or at all.

	So what do you think?  Has this been done before?
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"