Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!decvax!cca!ima!haddock!johnl
From: johnl@haddock.UUCP
Newsgroups: net.arch
Subject: Re: uP caches, cont'd. - (nf)
Message-ID: <12@haddock.UUCP>
Date: Sun, 11-Dec-83 23:35:23 EST
Article-I.D.: haddock.12
Posted: Sun Dec 11 23:35:23 1983
Date-Received: Tue, 13-Dec-83 02:53:18 EST
Lines: 30

#R:ucbesvax:27900003:haddock:9500003:000:1617
haddock!johnl    Dec 11 16:04:00 1983

I second M. Turner's remarks.  Cache memory isn't the same as registers.
There are speedup tricks people use on register files that don't make
sense for caches.  For example, the PDP-11/60 has two copies of the
register file, so that two register fetches can be active at once.  You
need to cycle both when storing a register, but register reads outnumber
writes enough in the PDP-11 that it's a win.  Storing the whole cache
twice (which makes it 1/2 as large as a singly stored cache) is not
likely to be a good idea, since you can't predict anywhere near as much
about memory use as you can about register use.

As another example, some machines with a regular register architecture
use this trick:  Instructions typically pick up one or two register
values, do something useful, and then store a value back.  To increase
instruction overlap, as it stores the result register from one
instruction, it sees if the same register is used in the next instruction
and gets the value from the data paths as it's stored, avoiding the
register read.  The 360/91 and perhaps other machines tried to do this to
memory references in general, but it's a lot more practical on a small
regular address space (the registers) than on a big wad of memory.

Finally, register addresses take fewer bits in an instruction than
general memory references, so instructions are smaller, so you can pick
up more of them with a given number of instruction fetches, lessening
interference between instruction and data access.

John Levine, decvax!yale-co!ima!johnl, ucbvax!cbosgd!ima!johnl,
{allegra|floyd|amd70}!ima!johnl, Levine@YALE.ARPA