Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/28/84; site lll-crg.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!gymble!lll-crg!brooks
From: brooks@lll-crg.ARPA (Eugene D. Brooks III)
Newsgroups: net.micro.68k,net.arch
Subject: Re: Re: RISC
Message-ID: <611@lll-crg.ARPA>
Date: Thu, 30-May-85 14:02:09 EDT
Article-I.D.: lll-crg.611
Posted: Thu May 30 14:02:09 1985
Date-Received: Sat, 1-Jun-85 01:47:57 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP>
Organization: Lawrence Livermore Labs, CRG group
Lines: 14
Xref: watmath net.micro.68k:838 net.arch:1284


The knee jerk answer to the instruction fetch bandwidth problem, cache,
is a valid answer.  The argument that one can give as much cache to a
complicated instruction set engine and therby get as much performance is
not valid.  The performance reduction for the complicated instruction set
comes from the time spent running microcode decode and execute instructions.

A good example of this is the VAX instruction set vs the Ridge instruction set.
The Ridge achieves the same performance as the VAX as a much lower hardware
cost.  The performance increase arises in the simplicity of the instruction
set.  This difference also shows up when you emulate these architectures
in software.  The instruction decode for such emulators on the vax is a
nigtmare and the designers of the VAX faced the same nightmare when the designed
the hardware and wrote the microcode for it.