Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site uiucdcsp
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsp!johnson
From: johnson@uiucdcsp.CS.UIUC.EDU
Newsgroups: net.arch
Subject: Re: VAX polyd instruction (and the
Message-ID: <3700002@uiucdcsp>
Date: Tue, 18-Mar-86 18:06:00 EST
Article-I.D.: uiucdcsp.3700002
Posted: Tue Mar 18 18:06:00 1986
Date-Received: Fri, 21-Mar-86 03:54:18 EST
References: <119@tekchips.UUCP>
Lines: 23
Nf-ID: #R:tekchips.UUCP:119:uiucdcsp:3700002:000:1308
Nf-From: uiucdcsp.CS.UIUC.EDU!johnson    Mar 18 17:06:00 1986


/* Written 12:06 pm  Mar 12, 1986 by stevev@tekchips.UUCP in net.arch */
>> Quite the contrary.  The evaluation of these primitives in hardware is not
>> necessarily a bad idea.  As long as it's done in a seperate functional
>> unit (and the archecture is pipelined) it is not a bad idea at all.

>One thing that has puzzled me about RISC machines is that its proponents
>argue that only a very basic machine should be on the main processor chip,
>with everything else done in separate functional units.

"Separate functional unit" does not mean "separate chip", but a separate
part of the chip devoted to a particular function.  SOAR is pretty much
a standard RISC.  Its special features would be useful for LISP as well as
Smalltalk.  There are essentially two new features.  The first is that a
check is made on each store that a particular memory-management invarient is
being maintained.  If it is not, the processor traps to a routine that fixes
it.  The second is that arithmetic routines check to be sure that the
arguments are small integers.  If not, the routines trap to the more general
solutions in subroutines.

There are groups working on RISCs for LISP and PROLOG.  RISC proponents
don't claim that special purpose processor design is dead, just that
special purpose instructions are dead.