Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!elroy!cit-vax!tybalt.caltech.edu!yair
From: yair@tybalt.caltech.edu (Yair Zadik)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <10544@cit-vax.Caltech.Edu>
Date: 1 May 89 10:59:25 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <288@ctycal.UUCP> <1262@l.cc.purdue.edu> <231@celit.UUCP>
Sender: news@cit-vax.Caltech.Edu
Reply-To: yair@tybalt.caltech.edu.UUCP (Yair Zadik)
Organization: California Institute of Technology
Lines: 26

In article <231@celit.UUCP> dave@celerity.UUCP (Dave Smith) writes:
>	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

A couple of years ago there was an article in Byte about a proposed design
which they called WISC for Writeable Instruction Set Computer.  The idea
was to do a RISC or microcoded processor which had an on board memory 
containing macros which behaved like normal instructions (I guess it was
on EEPROM like memory).  That way, each compiler could optimize the 
instruction set for its language.  The end result (theoreticly) is that
you get the efficiency of RISC with the memory bandwith of CISC.  I haven't
heard else about it.  Is anyone out there working on such a processor or is
it just a bad idea?

Yair Zadik
yair@tybalt.caltech.edu