Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!samsung!uunet!aablue!jb
From: jb@aablue.UUCP (John B Scalia)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: RISC vs CISC
Summary: This was a big consideration.
Keywords: Code Expansion
Message-ID: <615@aablue.UUCP>
Date: 22 Nov 89 14:23:15 GMT
References: <29806@iuvax.cs.indiana.edu> <17075@netnews.upenn.edu> <18323@watdragon.waterloo.edu>
Reply-To: jb@aablue.UUCP (John B Scalia)
Distribution: comp.binaries.ibm.pc.d
Organization: A A Blueprint Co., Inc. - Akron, OH
Lines: 22

In article <18323@watdragon.waterloo.edu> bwwilson@lion.waterloo.edu (Bruce Wilson) writes:
>This discussion about RISC vs CISC seems to conclude that a RISC
>machine by reducing the instruction set can run these instructions
>much faster but won't reducing the instruction set increase the
>number of instructions required to perform a specific task.

This was a major argument back when RISC was first argued as a possible
logical successor to current CPU designs. If you look at some of the
early arguments, the term "Code Expansion" comes up a lot. Some early
estimates argued that the amount of expansion that would take place would
negate any increase in speed. While I don't recall the specific values
argued, I generally remember a figure of 30% being bandied around.

Of course, modern compiler designs have pretty much rendered that argument
moot, by my understanding.

jb@aablue
-- 
A A Blueprint Co., Inc. - Akron, Ohio +1 216 794-8803 voice
UUCP:	   {uunet!}aablue!jb	(John B. Scalia)

Just a little more nonsense to clutter up the net.