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