Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: ERISC??? Message-ID: <1228@crdos1.crd.ge.COM> Date: 18 Oct 89 17:27:55 GMT References: <16190@vail.ICO.ISC.COM> <2393@gmu90x.UUCP> <1087@m3.mfci.UUCP> Reply-To: davidsen@crdos1.UUCP (bill davidsen) Organization: GE Corp R&D Center Lines: 43 In article <1087@m3.mfci.UUCP>, colwell@mfci.UUCP (Robert Colwell) writes: | It might help to consider a few more facts associated with this machine. | The first is that the guy who started the whole RISC juggernaut was John | Cocke, who was (and is) at IBM, and who was also involved (at least initially) | with this America processor. The second is that the papers on the IBM 801 | which enunciated the principles embodied therein don't emphasize the same | things that the research efforts at Berkeley & Stanford did, so it's not | that surprising that they don't religiously follow the tenets espoused | by them. Very well put. | | On the other hand, you could have a point. It just seems kinda weird to | accuse the guys who started all this of mere marketing ploys. Besides, | if the machine is as fast as they say, and if it doesn't qualify as a RISC | (under some hypothetical reasonable definition of RISC), then it would | seem some interesting (and undoubtedly amazingly inflammatory) conclusions | might present themselves... From what I've read and heard, the reason for developing RISC was *not* as an end in itself, but for speed. By reducing the cycles per instruction more instructions per send would be executed. Only to do that the instruction set was made smaller. Enter RISC. I am a true believer in reducing the cycles per instruction, but I see no virtue in having fewer instructions for any reason other than speed. I am not offended by a chip with 1024 instructions, if it averages 1.1 cycles/op. Note that the 80486 and 68040 have increased throughput at a given clock speed. Intel has claimed (actually one of the officers said it in a speech) that the 586 would be <1 cycle/op average. I assume Motorola is not ignoring this. IMHO too many people are concentrating on the number of opcodes rather than the performance on real problems. Let's remember that RISC was originally a solution to a performance goal, not some "natural principle" which could be defended even if it had hurt performance. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon