Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.arch
Subject: Re: RISC  a short answer??
Message-ID: <4847@june.cs.washington.edu>
Date: 5 May 88 20:28:14 GMT
References: <1036@nusdhub.UUCP> <1988May3.224604.2252@utzoo.uucp> <383@m3.mfci.UUCP> <770@l.cc.purdue.edu>
Reply-To: pardo@june.cs.washington.edu
Organization: U of Washington, Computer Science, Seattle
Lines: 27

In article <770@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>
>The philosophy of RISC seems to be, to quote one of the above articles, that
>one shoul not worry about the "slow" instructions to speed up 70% of the 
>instructions.  If the 30% slow instructions now run at 1/3 the speed of the
>fast ones, this would give an overall time of 1.7/instruction.  Now if the 
>time of the slow instructions was doubled, and the fast instructions run
>infinitely fast, the overall time would be 2/instruction.

Let me try to rephrase that a little:
    + If an instruction is executed very often, it ought to be fast.
    + If an instruction is hardly ever executed, it can be slow.

A parallel is rather like virtual memory.  If memory accesses are
almost always fast, then it doesn't matter much if they are really
slow once in a great while.

Therefore the RISC, or more appropriately, "streamlined" technique
is to weight all instructions by frequency of use.  Drop the ones
that aren't used often and concentrate on making the rest of them
fast.

One other decision that is often made is to expose underlying
grungy implementation details so that they can be exploited at
by a compiler to make things run faster.

	;-D on  ( Of course I *am* lying to you )  Pardo