Date: Tue, 14 Dec 1999 18:53:46 -0600 From: William Harold Newman To: cmucl-imp@cons.org Subject: It's alive! (SBCL, a CMU CL variant which bootstraps cleanly) Message-ID: <19991214185346.A1703@magic.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 4404 Lines: 80 I've made a system derived from CMU CL which can build itself from scratch, requiring only vanilla ANSI Common Lisp as a cross-compilation host. Basically, it works by building a portable version of Python in the cross-compilation host, then running that as a cross-compiler to produce the FASL files which describe the target Lisp, then running a portable version of GENESIS in the cross-compilation host to produce a .core file for the target Lisp. Unlike CMU CL, this system doesn't rely on host macros or host DEFTYPEs or host constants or host structure layouts or anything to determine the behavior of the target system. Therefore, under this system there should be no need to resort to hairy hacking when fundamental internal structures are to be changed, or to "compile it with itself a few times until things settle down". Besides bootstrapping changes and various internal implementation changes, the system has a number of externally-visible differences from CMU CL. Probably most significantly, I've gotten rid of, dropped support for, or changed the interface to many extensions, like WIRE, Hemlock, Motif, and various things in the EXTENSIONS package. The differences are already significant enough that I believe that calling the new system CMU CL would cause confusion, so I'm tentatively calling it SBCL instead (for "Steel Bank Common Lisp", after the industries where Carnegie and Mellon made the big bucks). A few days ago I got the system healthy enough that it can compile itself. The new code is under the same "released into the public domain" licensing as CMU CL itself, and I'd be happy to send a snapshot to anyone who's interested, or to put it up for anonymous FTP if someone would like to volunteer a site. Be aware that this is a snapshot of an unstable pre-alpha system, not just because of bugs but even more because my to-do list includes further planned changes in the interface. The system doesn't yet have any pretensions to being a useful platform to do real work with; I'm releasing it only because it might be interesting for people to look at or to play with. (Or to fix. Helpful suggestions and clean patches can be nice.:-) The system currently runs only on Linux 2.x for X86. I would like to port it to FreeBSD fairly soon. I don't have any non-X86 machines, so I don't have any immediate plans to port it to non-X86 hardware myself, but I believe it would be straightforward to port the system to other architectures supported by CMU CL by adapting the CMU CL machine-specific code. I've built the system under CMU CL (currently Debian cmucl_2.4.17) and under itself. I'd like to build it under CLISP, but I can't even begin to try until CLISP supports MAKE-LOAD-FORM. And I'd like to build it under ACL, but I don't have ACL. So I *think* it will be buildable under vanilla ANSI Common Lisps, but I don't have the resources to verify it. (Actually, in its current form, it does have some known portability problems. It probably couldn't be built on a host Lisp with a non-ASCII representation of characters, and it might have some minor problems on a host Lisp with a non-IEEE floating point representation. But since all Common Lisps I'm aware of use ASCII and IEEE, this is somewhat academic, and I think that given a non-ASCII and/or non-IEEE system for motivation and testing, it would be straightforward to fix these problems.) Currently it takes significant machine resources to bootstrap the system: peak memory usage in excess of 200 Mb and wallclock time on the order of an hour on my 450MHz/240Mb K6-3. I'm somewhat embarrassed about the bootstrapping memory usage (since IMHO any system which strains my P133/48Mb laptop is suspect:-) and I believe it should be possible to reduce it significantly with some tweaking. Meanwhile, for ordinary work, the memory usage of the system seems comparable to CMU CL; it's only bootstrapping that's ridiculous. By the way, if anyone likes the idea of clean bootstrapping, but doesn't like the other changes I've made, and is motivated to do a transformation like this on the main branch of CMU CL, I can try to help by giving a short summary of the right way to proceed, as well as my detailed log of the way I actually did proceed (false starts and all). -- William Harold Newman software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C