nathan@orstcs.UUCP (03/18/84)
Re: Cache vs. Registers
The comparison of cache speed vs register speed is
substantially correct; but the problems are much
overstated.
First, a small cache will have a comparator for every word
in it; all comparisons take place in parallel. If there are
few enough entries, buffering a signal to send to all those
comparators doesn't take very long.
Second, the "cache miss" case is supposed to happen rarely;
in any case, it won't take longer than doing an explicit
"reload register from memory" operation. In a cheap cache
one typically just uses the low address bits to select the
entry to be replaced (in other words, the replacement
algorithm is "nil"). This method is actually close to
ideal for a stack cache.
Arguments about reliability and bugginess are completely
correct, and call for very careful design.
In general, if such very commonly used registers as the
frame pointer and (perhaps) a single accumulator (which
could be treated as top-of-stack if you were a purist)
were set up as real registers,
I would expect the tradeoff to be in favor of slightly
slower "registers", as compared to the cost of doing
a "csave" at every procedure call. I have no explicit
statistics to support this, but it sounds like dandy material
for a master's thesis . . . except Burroughs probably did
it years ago.
------------------------------------------------
from the vicious cycle of:
>>----->>-------------( Nathan C. Myers )-----------------\
/ |
| ...!decvax!tektronix!ogcvax!hp-pcd!orstcs!nathan |
| nathan.oregon-state@RAND-RELAY |
\___________________________________________________/