Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <1989May4.161046.21510@utzoo.uucp>
Organization: U of Toronto Zoology
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <288@ctycal.UUCP> <1262@l.cc.purdue.edu> <231@celit.UUCP> <10544@cit-vax.Caltech.Edu>
Date: Thu, 4 May 89 16:10:46 GMT

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

Consider a well-built RISC, with an instruction cache, executing an
interpreter that fetches bytes from memory and interprets them as if
they were, say, 8086 instructions.  Assuming that the interpreter fits
in the I-cache, in what way does this differ from the WISC idea?

Context switching between interpreters is trivial, you can write them
in high-level languages, and if you really want *speed*, you can forget
the interpreter and just compile real code.

In short, it's an excellent idea and everyone is already doing it, but
without some of the limitations that result from thinking in terms of
microcode and EEPROM.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu