Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!unmvax!polyslo!cquenel
From: cquenel@polyslo.CalPoly.EDU (24 more school days)
Newsgroups: comp.arch
Subject: WISC (Bandwidth and RISC vs. CISC)
Message-ID: <10978@polyslo.CalPoly.EDU>
Date: 3 May 89 19:15:12 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>
Reply-To: cquenel@polyslo.CalPoly.EDU (24 more school days)
Organization: Blue Blaze Irregulars
Lines: 68

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

I believe the Clipper CPU chip does this, but it is not setable for each
process.  It is fixed for a given chip.  This set of built-in subroutines
was used for testing, some floating point (I think), and whatever code
they thought they didn't want to have to come through the i-cache.

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.

Another alternative would be to have a fixed number of sets of
micro-code, tailored for (for example)

	The kernel : with micro-code routines for
		     process management (load/store process context)
		     virtual memory management (cache flushing etc)

	pascal	   : maybe a different calling sequence

	fortran	   : with more tolerant aligment for handling
		     COMMMON block difficulties.

	LISP	   : get ideas from the bujillion micro-coded
		     LISP-stations on the market.

	C	   : be sure to put those nasty str* routines
		     in micro-code !


	etc etc etc


Anyway, you could have software traps to replace micro-code
that wasn't configured into the system, with slower conventional routines.

The site could decide which sets of micro-code they wanted to install
at kernel-link time.

Well, what do people think ?

I know it's a lot of trouble, but you could relieve a lot of the pressure
that RISC puts on the icache (and consequently the memory bus).

--chris

All I ask of life is a constant and exaggerated sense of my own importance.
-- 
@---@  -----------------------------------------------------------------  @---@
\. ./  | Chris (The Lab Rat) Quenelle      cquenel@polyslo.calpoly.edu |  \. ./
 \ /   |  You can keep my things, they've come to take me home -- PG   |   \ / 
==o==  -----------------------------------------------------------------  ==o==