🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2665

Re: ERISC???

#2665
From: Wm E Davidsen Jr
Date: Wed, 18 Oct 1989 17:27
43 lines
2792 bytes
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
Technical Details
Message-ID: <1228@crdos1.crd.ge.COM>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!crdgw1!crdos1!davidsen
References: <16190@vail.ICO.ISC.COM> <2393@gmu90x.UUCP> <1087@m3.mfci.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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