Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!decwrl!ucbvax!agate!web-1d!laba-3en From: laba-3en@web-1d.berkeley.edu (Raja S Kushalnagar) Newsgroups: comp.sys.amiga.hardware Subject: Re: 68040 vs RISC Message-ID: <1990Feb3.211701.15279@agate.berkeley.edu> Date: 3 Feb 90 21:17:01 GMT References: <1990Feb2.073513.29698@agate.berkeley.edu> <21699@pasteur.Berkeley.EDU> Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44) Reply-To: laba-3en@web-1d (Raja S Kushalnagar) Distribution: usa Organization: University of California, Berkeley Lines: 98 In article <21699@pasteur.Berkeley.EDU> lachesis@nyquist.bellcore.com writes: >>In article <1990Feb2.073513.29698@agate.berkeley.edu> laba-3en@web-1c (Raja S Kushalnagar) writes: >>it seems not to have surmounted the issue of efficient window register >>meshing, and probably might not be able to get over it at all, unless it >>goes more the RISC way, which it already seems to be going towards, but while >>retaining all the advantages of CISCs. If that can be done, it should really > >I beg to differ. During a study of MIPS vs. RISC by DEC's WRL, it was found >that a better compiler will *always* do better for code by using a large >register set instead of wasting all that register space using a register >window system. In fact, the prime reason why Berkeley did the RISC with >register windows was that the team producing the RISC and RISC II did not >include compiler experts. So, the 680x0 series could improve by adding more >registers, and improving compiler technology (especially register >allocation) to take advantage of those registers (as was done with the MIPS). Yes, it was true that the Berkeley team didn't have any compiler experts, but, the emphasis on increased compiler efficiency is a more of a software consideration than hardware, and shifts the burden excessively onto the compiler experts. And the RISC II did have 32 general registers. True, window mechanism might not allow as much optimization as say, on the MIPS, but it is an hardware solution, and thus amenable to dramtic performance improvements as hardware technology leapfrogs ahead. Hardware technology, by neccessity, is usually a couple of years ahead of software technology. A few years back, people got interested in a software solution for improving the CISC's, - Writable Control Store (WCS). This was devised to overcome the problem of computers running three or four microcycles per instruction - and make it possible for most instructions to be run in a single microcycle. It became popular, but eventually fell out of favour due to virtual memory and multiprocess complications. It didn't last more than a couple of years, I think. I am just drawing a comparision - I don't know if it's really justified, but it does seem that way. >The problem with a large register file is that when a context switch occurs, >the enter file has to be dumped. Also, the nesting level of functions, >should they exceed the (typically small) register window nesting level, will >cause an overflow and require a complete dump of all the register windows. >According to the WRL report (which I can't quote from since I don't have it >with me, see the technical report: Register allocation versus Register >windows by Digital Equipment Corp. Western Research Labs), this causes such >a performance penalty that MIPS, with its better compilers, came out >significantly faster. Most procedures generally have less than five or six variables, and almost never more than 10 - 12, and most of them are heavily used - a half to two thirds of the dynamically executed referenced to operands. Procedure calls are slowed down when there are a great many registers. So, having multiple register windows (or sets) means that registers would not have to be saved and restored on every procedure call. This works simply because of the generally ordered nature of programs - i.e nesting and loops. Programs rarely execute a long uninterrupted sequence of calls followed by an equally long uninterrupted sequence of returns. Now, that by itself, would probably be too slow to be justified, so the overlapping mechanism is used: Rather than copy the parameters from one wqindow to another on each call, windows are overlapped so that some registers are simultaneously part of two windows. So by putting parameters into the overlapping registers, operands are passed automatically. A disadvantage though, is that register windows use more chip area and of course the context switches. But the context switches occur rather rarely - about 100 to 1000 procedure calls for every switch. They require that two or three times as many registers be saved on the average, than chips without the register window mechanism. The penalty is not all that great, considering the speed up. You could very easily make a certain program run much faster on the MIPS than on the RISC and another program vice-versa. >In fact, with the advent of portable compilers, I'd warrant that it'll be >cheaper in the long run. (Just do the compiler once) I beg to differ. You just can't have a generic portable compiler and hope to make it exploit the architecture it is on, without any major tinkering. Also, optimizing compilers have a drawback in that they are much slower than conventional compilers (half the speed, even) and that they ignore the register saving penalty of procedure calls. >>RISC seems to be somewhat superior, given the current technological and >>economic constraints. It seems a bit shaky though. > >RISC is not shaky. Given the current technology, it is probably the only >architecture capable of being implemented on the latest (highest speed) >technologies like GaAr. You are probably right. It has taken an awfully long time for GaAr to become viable, though. I remember reading about them as far back as '81, though I doubt I understood what it really meant. :) >lachesis@nyquist.bellcore.com Raja. How can the very concept of junk bonds exist? The US has paid a big penalty for that. If a Milliken can get a 550 million salary, that is almost 0.1% of the entire US population income, I can't but help wonder. ############################################################################# raja@{soda,ocf,athena}.berkeley.edu | root@athena.berkeley.edu | laba-3en@web -----------------------------------------------------------------------------