🚀 go-pugleaf

In article <1174@brazos.Rice.edu> retrac@titan.rice.edu (John Carter) writes:
>In article <3989@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>>	Here's a (possibly crazy) idea for cache design.  [Stuff deleted.]
>>	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......
>>	So what do you think?  Has this been done before?

The issue is mostly a software issue.  Most microprocessors designed
with caching in mind from day one, and many implementations of earlier
architectures include MMUs that offer at least a cache/nocache bit
per MMU map entry.  Any of the high-performance RISCs, and most of the
CISC chips do this.  In any of the MMU designs that permit double-mapping,
the same physical page can be double-mapped with 2 MMU entries, one
cached, the other uncached, so if the software can figure out what to do,
and keep reasonable consistency, all might be well.

MIPS R3000s use one of the address bits to distinguish between
cached/nocached access for the "unmapped" part of the kernel address
space, and actually uses this in various ways.  For example, you can
call a function, cached, in the usual way.  If you call it by jumping to
the same address | 0x20000000, when you get there, you're running
uncached.....  this feature is actually used, by the way.
RISC/OS also takes advantage of uncached address space in those
configurations (i.e., most R2000-based machines), where it is faster
to read disk blocks into buffers and copy from them uncached,
thus avoiding trashing the cache unnecessarily. (This is not so
clear-cut on R330s that do multi-word refill; another strategy might
be better).

However, to my knowledge, we do not make use of this for ordinary user
programs of the form implied by the original question; rather it is
restricted to manual choice where people know a priori that this is
what they want.

Understanding the useability of software-controlled caching is
a good area for research over the next few years; the answers are not
yet clear.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086