Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!sco!seanf From: seanf@sco.COM (Sean Fagan) Newsgroups: comp.arch Subject: Re: More RISC vs. CISC wars Message-ID: <3034@scolex.sco.COM> Date: 13 Jul 89 21:28:04 GMT References: <2190@oakhill.UUCP> <13980@lanl.gov> <42550@bbn.COM> Reply-To: seanf@scolex.UUCP (Sean Fagan) Organization: The Santa Cruz Operation, Inc. Lines: 47 In article <42550@bbn.COM> slackey@BBN.COM (Stan Lackey) writes: >In article <13980@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>But, RISC machines are easier to pipeline >I don't see how this can be true, other than possibly in the scoreboarding >logic. If it has it. "Most" "CISC" machines have those wonderful complex addressing modes we all know and love, which oftimes means a variable length instruction (best example is, of course, the VAX). This is rather difficult to pipeline, although not impossible. One of the features most "RISC" chips have in common is a limited amount of instruction formats. For example, the Cyber 170 machines (knew I'd put this in somewhere, didn't you? 8-)) had two formats, 15 and 30 bits wide. If I remember correctly, the i860 has 5 or so (but, sizewise, it only works out to 2 or 3), and the 88k looks like it's similar. >>Micro- >>coding slows the machine down. >This is an interesting statement. As I recall hearing, Cray started >this perception back in the 70's. I thought it had been proven wrong. Bad thing to say. As far as I knew, it had been proven that microcoding *did* slow the system down, since you could always, worst case, make your microcode be your instruction set, and use a cache to execute the "real" code normally, and execute the ucode directly when you wanted more speed. >For example, the Alliant executes the instruction: > add.d (an)+, fp0 >in one cycle (yes, that's double precision memory-to-register add, >auto increment), and it's microcoded. Are you saying that it would be >done in zero cycles if we got rid of the microcode? Gee, and after >spending so much real estate on those microcode RAM's... As somebody else said, in regards to Elxsi: if you most complex instructions take as much time as your simplest ones, then your cycle time is too long (or something like that). Usually, the reason cycle times are chosen to be longer than they need to be is a) the hardware isn't up to snuff (e.g., ETA), or b) you need a longer cycle to get more work done. RISC advocates (and I find myself in that group this time) claim that, if b) is chosen, then you should simply make your cycle time shorter and go with a different instruction set (or algorithm in the hardware). -- Sean Eric Fagan | "Uhm, excuse me..." seanf@sco.UUCP | -- James T. Kirk (William Shatner), ST V: TFF (408) 458-1422 | Any opinions expressed are my own, not my employers'.