🚀 go-pugleaf

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.
--