Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!barmar
From: barmar@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.arch,net.ai,net.lang,net.lang.lisp
Subject: Re: Lisp Machines
Message-ID: <4328@mit-eddie.UUCP>
Date: Thu, 23-May-85 01:44:11 EDT
Article-I.D.: mit-eddi.4328
Posted: Thu May 23 01:44:11 1985
Date-Received: Fri, 24-May-85 23:32:15 EDT
References: <922@noscvax.UUCP> <5604@utzoo.UUCP> <3345@utah-cs.UUCP> <4314@mit-eddie.UUCP> <3346@utah-cs.UUCP>
Reply-To: barmar@mit-eddie.UUCP (Barry Margolin)
Organization: MIT, Cambridge, MA
Lines: 79
Xref: watmath net.arch:1243 net.ai:2790 net.lang:1584 net.lang.lisp:458

In article <3346@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley shebs) writes:
>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.

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.

>  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).

Not in a language that provides generic operations but doesn't require
type declarations (see below); in this case, the type-checking is
necessary in order to dispatch.  By the way, about half the bug reports
that I see being sent from MIT Lisp Machine users are generated because
the software made an error that would not be caught by most compiled
Lisp implementations: array bounds and argument types; similar bugs in
Multics Emacs (written in Maclisp) generally cause random errors (like
faults during GC) to start occurring.  Personally, I prefer it when
software stops as soon as the bug occurs, rather than waiting until
twenty minutes later.  Of course, the best thing is for the code not to
have any bugs, but that is not an option as long as people are doing the
programming.

>There are better ways to ensure robustness; after all, we don't put
>usually put checksums with every byte on the tape.

How about parity bits?  Or ECC bits in every word of memory?  Is there
that much of a leap from ECC that checks that the memory word is correct
to tag bits that are used to check that the triple (operation,arg1,arg2)
is correct?  I don't think so.

>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.

>>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!

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.

					barmar
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar