gumby@Cygnus.COM (David Vinayak Wallace) (11/05/90)
Date: 2 Nov 90 14:02:11 GMT From: gjc@paradigm.com You know what would improve the state of the art of lisp implementations a bit? If somebody wrote a LISP front-end to GCC. Jim Miller and I discussed this at the last Lisp conference, using GCC as the back end for GAMBIT. You're right in that it wouldn't be that hard, though there is a little more work than you implied. Looking over my notes: PVM (GAMBIT's representation) or s-codes are a little higher-level than rtl in that rtl doesn't understand things like closure variables (e.g. for CL it could compile flet only if you didn't use upward funargs) and a little low-level (ie rtl can represent loops, so that it can do various optimisations; PVM represents loops with branch instructions). To do a decent lisp with GCC would require the following modifications: The addition of an apply operator, since the calling conventions differ, and a modification to procedure code generation so that functions could have lisp entry points and optimised (post-arg- checking) entry points for calling by C code and perhaps for compiler-generated calls when the arity and type are known at compile time. The calling sequence would have to be fixed too, of course. The real problem is GC. You really want to tell the compiler about register conventions it should share with the GC. Unfortunately most processors now have register usage conventions which are followed by C compilers and which don't allow you to be able to depend on this. Also, several new machines have register windows which make it expensive for the GC to scan the machine state (register windows also make it extremely unpleasant to use any sort of closure as a funarg). GCC naturally uses register windows heavily on the machines which implement them. We're modifying GCC to allow certain kinds of conservative GC without scanning the machine registers or stack, but this isn't cheap either. If you removed the requirement that the compiler trivially intercall with existing programs then this would become a lot easier. Using GDB on generated code would be easy in any case, but you'd lose all the benefits of having lisp in your debugging environment! Perhaps the thing to do would be to link parts of GDB into your runtime. The reason the FSF isn't doing anything like this appear to be a two (but I don't speak for them): rms' priorities lie in different areas, and you can't really just write a compiler: you have to write a whole lisp implementation. Brian Fox wants to work on one; has anyone some money for him?