Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!utah-cs!shebs
From: shebs@utah-cs.UUCP (Stanley Shebs)
Newsgroups: net.arch,net.ai,net.lang,net.lang.lisp
Subject: Re: Lisp Machines
Message-ID: <3346@utah-cs.UUCP>
Date: Wed, 22-May-85 10:04:30 EDT
Article-I.D.: utah-cs.3346
Posted: Wed May 22 10:04:30 1985
Date-Received: Fri, 24-May-85 03:38:32 EDT
References: <922@noscvax.UUCP> <5604@utzoo.UUCP> <3345@utah-cs.UUCP> <4314@mit-eddie.UUCP>
Reply-To: shebs@utah-cs.UUCP (Stanley shebs)
Organization: Univ of Utah CS Dept
Lines: 35
Xref: watmath net.arch:1241 net.ai:2788 net.lang:1583 net.lang.lisp:457

In article <4314@mit-eddie.UUCP> barmar@mit-eddie.UUCP (Barry Margolin) writes:

>The point is that on a Lisp Machine you don't sacrifice any type
>checking in order to get optimal performance.  If you are adding two
>fixna then it takes just as long as a fixed point addition instruction
>on any other machine.  In order to get all the checking that the Lisp
>Machine implements on conventional hardware you would have to slow down
>the code for "+" by a factor of two or three; for this reason, most Lisp
>cmpilers for conventional machines don't generate type checking code,
>and users must use the interpreter to get this checking.  Most Lisp
>Machine programmers I know do all their debugging on compiled code,
>which would be unthinkable on most other systems.

I don't know why debugging compiled code is such a wonderful thing;
object code (even on a LM) is not particularly readable.  With the
interpreter you can see exactly what is being executed.  While runtime
type checking does increase robustness, it's usually an incredible
waste of resources; 99.99999% of type tests will return a result that
is knowable in advance (the remaining .00001% are bug detections).
There are better ways to ensure robustness; after all, we don't put
usually put checksums with every byte on the tape.

In general, I tend to object to doing complex operations (like typechecking)
in hardware - it's just too inflexible.  Does anybody really believe
that the primitive types in Zetalisp are worth wiring into the machine
(or even the microcode)?

>Another place where special hardware can be a big win is in garbage
>collection.

I agree, but a GC coprocessor is really all you need.  Actually, it
would be better just to have a vanilla multiprocessor, and run GC
tasks concurrently with computation tasks, but that's still in research!

							stan shebs