Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!bbn!bbn.com!slackey From: slackey@bbn.com (Stan Lackey) Newsgroups: comp.arch Subject: Re: Register usage Message-ID: <40718@bbn.COM> Date: 31 May 89 21:49:57 GMT References: <259@mindlink.UUCP> <25382@ames.arc.nasa.gov> <18965@cup.portal.com> Sender: news@bbn.COM Reply-To: slackey@BBN.COM (Stan Lackey) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 45 In article <18965@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes: >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. I strongly suspect the RISC guys are, as we speak, analyzing stuff like: What kind of sequences frequently show up How to handle register dependencies and overutilized facilities Should totally independent instr's go in parallel only, or can dependent ones be issued and then pipelined (load to r0 followed by add to r0) Let me guess what they're finding. Correct me if I'm wrong. Load/store followed by increment/decr of the address is common. Load followed by dependent use of the data is common. Decrement of register, followed by test (compare or just zero), followed by branch, is common. Addition to register followed by its use as an address. Bunch of loads in a row, bunch of stores in a row. [I could probably think of more with more time.] Look familiar? This prompted my first reaction when RISC started getting popular: Where do they go from here? Yes, it's an interesting technology opportunity. But I'd rather implement the next generation machines as CISC's rather than RISC's, IF I HAVE TO STAY INSTRUCTION SET COMPATIBLE. 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. 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. -Stan [Disclaimer: Do I have an opinion yet?]