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!linus!philabs!cmcl2!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: <3349@utah-cs.UUCP>
Date: Fri, 24-May-85 10:54:59 EDT
Article-I.D.: utah-cs.3349
Posted: Fri May 24 10:54:59 1985
Date-Received: Sat, 25-May-85 07:08:20 EDT
References: <922@noscvax.UUCP> <5604@utzoo.UUCP> <3345@utah-cs.UUCP> <4314@mit-eddie.UUCP> <3346@utah-cs.UUCP> <4328@mit-eddie.UUCP>
Reply-To: shebs@utah-cs.UUCP (Stanley shebs)
Organization: Univ of Utah CS Dept
Lines: 69
Xref: linus net.arch:1061 net.ai:2572 net.lang:1372 net.lang.lisp:413

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

>The Lisp Machine compiler puts enough information in compiled code so
>that it is easy to relate to its source code.  For instance, variable
>names are still available when debugging compiled code.  When a function
>stops with an error there is not much more that you can do with it if it
>is being interpreted than if it is being executed from compiled code.

In the "primitive" PSL runtime environment, it's possible to edit the
expression whose evaluation caused an error, as long as it's interpreted.
This is invaluable when fixing nuisance bugs (like mismatched numbers
of args).  And of course variable names are always available.

>>In general, I tend to object to doing complex operations (like typechecking)
>>in hardware - it's just too inflexible.
>
>The alternatives are either (1) doing type checking in software or (2)
>adding type declarations to programs.  For those of you who think I
>should add (3) do code analysis that determines the parameter types,
>please explain how a compiler is to perform such an analysis when the
>entire compilation unit contains a single function definition such as:
>
>(defun sample-function (arg1 arg2)
>       (sample-function-2 (+ arg1 arg2))
>
>Without the user adding type declarations, as in
>
>(defun sample-function (arg1 arg2)
>       (declare (fixnum arg1 arg2))
>       (sample-function-2 (+ arg1 arg2))
>
>(or the implicit declaration facility, such as Maclisp's +/+$/plus
>distinction) there is no way for the compiler to know that it can
>compile the (+ arg1 arg2) into a simple ADD instruction.

I exaggerated about the 99.9999%.  It's probably more like 99%, in
average code; the remaining 1% being operations that are being
used in a truly generic way.  LM code probably has a higher percentage
of generic ops, but examination of the source code suggests to me
that many of the generic flavor-mixing operations are gratuituous.

On the other hand, ML does full type inference all the
time, and I don't know of any inherent reason that Lisp can't do
that also.  The above example is unrealistic - presumably sample-function
and sample-function-2 have a context, and type inference starts
from that context.  All that can be done with the above example
is to infer that sample-function and sample-function-2 return the
same type that + does; just a number.

>>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!
>
>I suggest you read David Moon's "Garbage Collection in a Large Address
>Space Lisp Implementation", in the Proceedings of the 1984 ACM Symposium
>on Lisp and Functional Programming.  Without special assist it is really
>hard to prevent the GC from seriously impacting your paging performance,
>as most GC's need to look at nearly all of virtual memory.  The above
>paper describes the mechanism used in the Symbolics 3600 to implement a
>very good garbage collector that doesn't need to page in lots of memory.

I heard the paper, and I read the proceedings, and the paper is a case
study rather than a general treatise on the topic.  There's not much to
convince me that the mechanism is general enough to be useful anywhere
else.  The idea of several kinds of spaces has been around for awhile,
but most of the other details are 3600-specific.  It's also not clear to
me what the performance results were supposed to prove.

							stan shebs