Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!rutgers!rochester!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.arch
Subject: Re: WISC (Bandwidth and RISC vs. CISC)
Summary: Yes, WISC is still alive.
Message-ID: <4904@pt.cs.cmu.edu>
Date: 4 May 89 20:38:07 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <288@ctycal.UUCP> <10978@polyslo.CalPoly.EDU>
Organization: Carnegie-Mellon University, CS/RI
Lines: 42

In article <10978@polyslo.CalPoly.EDU>, cquenel@polyslo.CalPoly.EDU (24 more school days) writes:
> In 9680 yair@tybalt.caltech.edu.UUCP (Yair Zadik) sez:
> >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

WISC Technologies built two such processors, a 16-bit and a 32-bit processor.
The Byte article described the 16-bit processor in somewhat generic terms.
The technology has since been licensed to Harris Semiconductor, and forms
the basis for their 32-bit RTX (Real Time Express) chip now in development.

> As has already been pointed out, doing this on a process specifiable
> level would be a hassle for context switching.  If you already have
> an icache and a dcache on-chip, you could have a micro-code cache
> as well.  If you didn't worry about "mixing" them, you could have
> room for 2 or 4 sets of micro-code and have each set tagged with the
> process ID in some way.  You could either fault each set of micro-code in 
> in chunks, or do the whole thing at one time.

The original processors used RAM control store and required a host processor.
Real-live chips that could be used in a stand-alone mode are being built
that have ROM for a core instruction set and RAM for application-specific
instructions.  Since the primary application is real-time embedded control,
it is *not* important to worry about managing the control store RAM, since
the programmer gets to determine the instruction set at compile time.
This is not at all like a multi-user workstation environment, where contention
for a limited amount of control store by several large programs written
by different companies can be a problem.

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  5551 Beacon St.
  Pittsburgh, PA  15217    
Recent PhD graduate at CMU and sometime consultant to Harris Semiconductor.
I speak only for me, etc.  But, I am the one who wrote the Byte Article.
--