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> Date: Sun, 6 Jan 91 01:49:25 GMT In article 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