Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!sun!imagen!atari!portal!cup.portal.com!bcase From: bcase@cup.portal.com (Brian bcase Case) Newsgroups: comp.arch Subject: Re: Register usage Message-ID: <19046@cup.portal.com> Date: 1 Jun 89 18:52:59 GMT References: <259@mindlink.UUCP> <25382@ames.arc.nasa.gov> <18965@cup.portal.com> <40718@bbn.COM> Organization: The Portal System (TM) Lines: 61 >>For the implementations to come, including >>superscalar stuff, the issues will be the complexity of implementation and >>the cost (read: people) of realizing that implementation. This is where >>CISCs, I believe, will faulter. One of the great advantages of RISCs is >>that they are conceptually easier to implement. > >In order to go superscalar, future RISC chips will end up having new, >incompatibile architectures. I make this statement because I understand >the difficulty of the alternative, which is the execution of several >existing-architecture instructions concurrently. By definition, a superscalar implementation of an architecture is an implementation that *is compatible* with previous non-superscalar implementations. It doesn't make sense to say that to go superscalar, future RISC chips will have incompatible architectures. New things will certainly be learned about the interactions between architcture and implementation, but that doesn't mean that current RISC architectures won't have superscalar implementations. They are in the works as we type.... >In other words, I think that when they learn how to >implement a fast CISC, it will go faster than the same-technology >RISC. Why? Because for the RISC to keep up, it will have to execute >an average of two instructions per cycle, and one instruction is a lot >easier to implement than two, even with auto-increment addressing. First of all, the fast CISCs that we are seeing, 486 and 68040, are looking more and more like RISCs, to the extent that that is possible. That is, the simple, pipelinable instructions go fast while the complex, inherently serial instructions go slow. This trend will only increase. Note that the fast CISC, which have *next generation* technology on their side, are still not faster than current technology RISCs. The process of subsetting a CISC's instruction set and changing the compilers to take advantage of the fast subset is the only way for a CISC to go reasonably fast. For a superscalar implementation of a CISC, the subsetting will get more severe, I predict. Trying to execute two complex instructions, with side effects, at the same time is much harder to understand and implement (correctly) than trying to execute two simple instructions, relatively free of side effects, at the same time. >Of course, there is always the possibility to do what they did the >first time: come out with a new architecture that matches the >technology window exactly. Note recent product announcements: this >just keeps happening! It's just that when you do this, expect a >limited lifetime of the architecture. The commercial introduction of new architectures is completely up to companies. If a new architecture facilitates superscalar, or super- mumble, implementation, then it is the job of academics to discover and document it. I guess I am saying that no one should expect that CISCs will make a comeback because of the desire to build superscalar implementations. Quite the contrary. On limited lifetimes: If we only had a portable means of distributing applications, such as that proposed by the OSF ANDF (application-neutral distribution format), then we could innovate at the architectural level 'till we're blue in the face (maybe we already are). An architecture might be in vogue for a limited amount of time, but with ANDF, it would still be able to run new software.