skef@cmu-cs-spice.ARPA (Skef Wholey) (05/22/85)
> From shebs@utah-cs.UUCP (Stanley Shebs) Mon May 20 10:08:08 1985 > > Compiled PSL code wins big because it sacrifices some reliability and > debuggability of code for speed. Also, to get the best performance, one > must use several kinds of declarations and flags. The net effect is to > compile away a large percentage of function calls and type checks. Runtime type checking is one of the biggest things Lisp has going for it. Yes, you can get away without it in "debugged" systems, but no large system is ever completely bug free. Runtime type checking gives Lisp programs an amazing amount of robustness. An anecdote: when Hemlock (the Spice Lisp text editor) was being written, the guy doing the redisplay code wrote an large amount of very tense, very complicated code. There were a few bugs left in the several thousand lines of code that had been "debugged". Hemlock was used by many people for months while these bugs rose to the surface. In each case, the bug quickly led to the program attempting to perform some operation on an object of the wrong type. Such errors were of course caught immediately, and finding the bugs was pretty easy. Has this code been compiled with the "damn the type bits, full speed ahead" philosophy, the bugs would have probably led to a corruption of the Lisp system's integrity, and a big mess in which the bug would be obscured. In such cases (i.e. in "production software"), it is just not feasible to try things with less type checking, since one might not have any idea of where the bug is. Requiring copious declarations to get the compiler to generate good code takes a big bite out of programmer productivity. > The moral? Fixing the compiler is a better approach than sinking > millions of dollars into hardware, then trying to sell it as an > "advanced AI engine" or "powerful Lisp machine"... Most people doing AI need to do rapid prototyping. Runtime type checking and declaration-free programming are two extremely useful software engineering tools. Most people doing AI also need speed. Incremental garbage collection is more easily done with hardware assist than without. Currently, the only way to get all these things is with specialized hardware. Unfortunately, that hardware is expensive. However, a "conventional" computer architecture can be augmented to perform runtime type checking (and a crude form of runtime type dispatch) as well. The Smalltalk On A RISC (SOAR) chip adds two features to a RISC: Generic arithmetic (traps on non-"fixnum" operations) Incremental GC (traps when "oldspace" pointers are fetched) A third hardware feature needed for Lisp is address type checking -- that is, one would specify a type code (tag) along with the effective address, and the hardware would verify that the resulting address has the right tag bits. Note that none of these features need detract from a good machine instruction set. Untyped instructions are already there, and few architectures are extremely tight on opcode space. RISC machines have plently of opcode space available, in fact. --Skef -- uucp: ...!seismo!cmu-cs-spice!skef arpa: skef@CMU-CS-Spice