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