Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!rutgers!apple!oliveb!sun!chiba!khb
From: khb%chiba@Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <102714@sun.Eng.Sun.COM>
Date: 3 May 89 18:21:07 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <288@ctycal.UUCP> <1262@l.cc.purdue.edu> <231@celit.UUCP> <10544@cit-vax.Caltech.Edu>
Sender: news@sun.Eng.Sun.COM
Reply-To: khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS)
Organization: Sun Microsystems, Mountain View
Lines: 32

In article <10544@cit-vax.Caltech.Edu> yair@tybalt.caltech.edu.UUCP (Yair Zadik) writes:
......
>>"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?
>

Honeywell and Buro..whoops UNISYS had mainframes like this, well over
a decade ago. Byte, lives at the cutting edge....

Performance is similar to having a RISC with a seperate instruction
cache (of some reasonable size). This is, in fact, often better
because different programs (we do live in a world full of context
switches) probably want different "microcode" ... 

cheers




Keith H. Bierman      |*My thoughts are my own. Only my work belongs to Sun*
It's Not My Fault     |	Marketing Technical Specialist    ! kbierman@sun.com
I Voted for Bill &    |   Languages and Performance Tools. 
Opus  (* strange as it may seem, I do more engineering now     *)