Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site phri.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!vax135!timeinc!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: net.arch
Subject: Re: Orphaned Response ((Cache, actually))
Message-ID: <142@phri.UUCP>
Date: Tue, 15-Jan-85 11:10:09 EST
Article-I.D.: phri.142
Posted: Tue Jan 15 11:10:09 1985
Date-Received: Fri, 25-Jan-85 09:10:10 EST
References: <-257100@dartvax.UUCP> <1500001@hp-dcde.UUCP>
Organization: Public Health Research Inst. (NY, NY)
Lines: 49

> Now suppose we had a cache that was much more under a programmer's control.
> And suppose our processor has a load cache instruction with syntax:
>     load cache <cache address> <memory address>
> dartvax!chuck
> /* ---------- */
> 
> I think the biggest problem right now is the compiler technology.  The
> compiler would have to recognize instruction locality when it occurs in a
> program.
> Perry Scott, !hplabs!hpfcla!perry

	Maybe the compiler could get some help from the programmer.  We
already have register variables, why not have an extension to C which
allows CACHEON and CACHEOFF keywords?  OK you guys from the C Standards
committee, flame on, I'm ready for you; so we'll call it C++prime-star :-).
These could be used to bracket that section of code you want to make sure
gets cached.

	It is probably a given that anything bigger than a micro will have
some kind of cache (I'm not sure about 68K based systems, anybody know?)
and the variability in the size, update strategy, and organization of
caches should be no worse a problem than the corresponding differences in
register sets. Besides, just as with the REGISTER keyword, the compiler
takes this as a hint which it is free to ignore if it doesn't make sense
for the particular machine architecture.

	Perhaps instead of having bracketed sections of code, we could have
a CACHE keyword which is only valid in a function declaration and makes the
whole function get cached (yeah, I know, what if the function is 2.3Kbytes
of code and you only have 2K of cache?)  This later version would be
particularly good for things like interrupt routines which run often, but
usually with enough other stuff in-between invocations to flush the cache.

	Possibly, you would want the load cache instruction to be
kernel-mode-only to keep user code from hogging it???  Perhaps you want 1
part of the cache to be programmer allocatable using the load cache
instruction and part to be up for grabs???  Perhaps even 1 part reserved
for kernel allocation, 1 part for user allocation, 1 part up-for-grabs data
and 1 part up-for-grabs text (hey, it's got to be power-of-2, right?)  Hey,
why not do something really clever and put J-11's in all the device
controllers and give everybody a micro-vax II in their terminal so the cpu
doesn't have to do anything at all :-)

-- 
Don't blame me, I just work here....

{allegra,seismo,ihnp4}!vax135!timeinc\
                 cmcl2!rocky2!cubsvax >!phri!roy  (Roy Smith)
                      philabs!cubsvax/