Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!tektronix!nosun!fpssun.fps.com!celit!dave
From: dave@celerity.uucp (Dave Smith)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <231@celit.UUCP>
Date: 28 Apr 89 22:34:29 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <288@ctycal.UUCP> <1262@l.cc.purdue.edu>
Sender: news@celerity
Reply-To: dave@celerity.UUCP (Dave Smith)
Organization: FPS Computing Inc., San Diego CA
Lines: 29

In article <1262@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>In article <288@ctycal.UUCP>, ingoldsb@ctycal.COM (Terry Ingoldsby) writes:
>> My point is that since almost everything is written in high level languages
>> today, they are better suited for RISC.  For applications that still use
>> assembler (eg. control systems) CISC makes sense.
>
>Must we only use tools that would appal an artist?  Programming is an art;
>artists do not learn by filling in the squares with numbered colors.
>

	A good artist can create fine art with crayons or oil paints (or
whatever).  Assembly languages are definitely the crayons of the computer
world.  RISCs are kind of like the little box of Crayolas with 16 colors,
a CISC, like the VAX, is like the big box with 64.  Ever notice how it was
that the black, red and blue crayons always ended up the smallest in that
big box and the mauve crayon looked brand new?

	The problem I have with RISC designs are that they use up too much
memory bandwidth.  What I think would be better was something that gave you
the flexibility of a RISC (not being tied into the designer's particular
idea of how a string instruction should be implemented, for example) but 
with the memory bandwidth efficiency of a CISC.  I'm not familiar enough
with VLIW to make any good judgements on it, but it seems as though it's
a reasonable way to go.

David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave
"Repent, Harlequin!," said the TickTock Man