Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!zinfandel!hplabs!hp-pcd!hp-dcde!perry
From: perry@hp-dcde.UUCP (perry)
Newsgroups: net.arch
Subject: Re: Orphaned Response
Message-ID: <1500001@hp-dcde.UUCP>
Date: Thu, 10-Jan-85 13:36:00 EST
Article-I.D.: hp-dcde.1500001
Posted: Thu Jan 10 13:36:00 1985
Date-Received: Tue, 15-Jan-85 01:32:10 EST
References: <-257100@dartvax.UUCP>
Organization: Hewlett-Packard - Fort Collins, CO
Lines: 28
Nf-ID: #R:dartvax:-257100:hp-dcde:1500001:37777777600:1268
Nf-From: hp-dcde!perry Jan 11 10:36:00 1985
/***** hp-dcde:net.arch / dartvax!chuck / 8:35 pm Jan 9, 1985*/
Now suppose we had a cache that was much more under a programmer's control.
To be concrete, suppose we have a cache of say, 32 elements each containing
32 words. And suppose our processor has a load cache instruction with
syntax:
load cache
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. Another intelligent approach is locality lookahead, similar to
the instruction lookahead which has been done on the big machines for years.
This all sounds like a compiler-writer's nightmare to implement. I have not
yet seen a compiler optimized for cache technology.
Of course, assembly-level programmers could hand-code this instruction,
but I think that would be a step backward (or sideways).
You allude to the idea of a segmented cache. The idea of RISC-type register
files might be applicable to caches. Especially in environments which tend to
switch contexts rapidly (such as a program making a lot of OS calls),
this may avoid the problem of voiding a valid cache on a context switch.
Perry Scott
!hplabs!hpfcla!perry