Newsgroups: comp.arch
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: more registers for ix86, was: Let's pretend
Message-ID: <1991Jan6.014925.10935@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <3042@crdos1.crd.ge.COM> <1990Dec26.020034.4131@lpi.liant.com> <5827@labtam.labtam.oz> <KENW.91Jan3123808@skyler.calarc.ARC.AB.CA>
Date: Sun, 6 Jan 91 01:49:25 GMT

In article <KENW.91Jan3123808@skyler.calarc.ARC.AB.CA> kenw@skyler.calarc.ARC.AB.CA (Ken Wallewein) writes:
>... I sometimes wonder whether registers aren't actually an
>optimizing kludge, and that an instruction set which made no explicit
>reference to registers at all might be more efficient.

"More efficient" in what sense?  The fact is, if you have compilers that
can do intelligent and useful things like common-subexpression optimization,
there is a very high payoff for having a modest number of random-access
variables that are implemented in very fast storage and can be addressed
with very few instruction bits.  These need not be "registers" in the
traditional sense, as witness CRISP's use of special addressing modes
and a special cache for the very top of the current stack frame, but they
have to look a lot like them.

The major alternatives to explicit register references in instructions
are memory-to-memory machines and stack machines ("stack" here in the sense
of expression-evaluation stack, not call stack).  Memory-to-memory machines
lose big on the number of bulky memory addresses needed when expressions
start needing temporaries.  Stack machines lose big on the difficulty of
keeping useful values around for re-use, since the stack really wants to
throw a value away after using it.  Both lose big on the cost of memory
references unless the cache is *very* good.  Given good compilers, register
machines perform better at equivalent complexity:  that easily-accessed
fast temporary storage is very useful.

>  Speaking of caches, I seem to recall that single-storage-area caches
>are supposed to be more efficient than caches which have separate
>areas for different things...

Again, "more efficient" in what sense?  Current experience strongly points
to the reverse, at least for the obvious case of instructions vs. data.
Splitting a cache loses the ability to use any free space to fulfill a new
request, but gains the ability to specialize the hardware and parallelize
data paths.
-- 
"The average pointer, statistically,    |Henry Spencer at U of Toronto Zoology
points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu   utzoo!henry
