SBCL, a new free Common Lisp based on CMU CL 
Author Message
 SBCL, a new free Common Lisp based on CMU CL

I'm working on SBCL,
        http://www.*-*-*.com/
a variant of CMU CL which should be easier to
maintain than CMU CL. Some of the changes involved -- especially
making the system bootstrap itself cleanly -- involved major surgery
on the CMU CL code base, not just local patches, and the result is a
distinct version of the system.

I consider the new release of SBCL (sbcl-0.6.0) to be alpha quality,
unstable but fairly usable.

Some changes in sbcl-0.6.0 relative to CMU CL include:
  * The system can bootstrap itself cleanly, unlike CMU CL, whose
    bootstrap process involves elements of mutating a running CMU CL
    into a new executable. Thus
    ** Arbitrarily large changes to SBCL can be made without having to
       set up special hacks to keep the changes from breaking the
       cross-compilation host. (Such bootstrapping issues are a
       fertile topic of conversation on the CMU CL list, but should
       not be interesting in SBCL.)
    ** The target system is completely described by the source code
       of the current version, without stealth contributions from
       the source code from previous versions. (It should not be
       interesting to "recompile the system with itself a few times
       until things settle down".)
  * There are some improvements in ANSI compliance (especially in the
    behavior of PRINT-OBJECT and STYLE-WARNING).
  * There are various other bug fixes.
  * Many non-ANSI extensions have been simplified, e.g. environment
    variable handling, options to COMPILE-FILE.
  * Many non-ANSI extensions have been cleaned up, e.g. i/o handling in
    the de{*filter*}.
  * Many non-ANSI extensions are no longer supported, e.g. sockets,
    X11, and the Hemlock editor.

The SBCL system is smaller than CMU CL, but as of 0.6.0 that doesn't
really show up in the size of compiled code, since the sbcl-0.6.0
core is entirely native code, while CMU CL uses byte compilation for
non-speed-critical code. "Entirely native code" sounds a little like a
feature, but it's really a bug, which will probably be fixed at some
point. Once SBCL can byte compile itself, the compiled code for SBCL
should become significantly smaller than CMU CL.

Version 0.6.0 of SBCL has a number of drawbacks compared to CMU CL:
  * It's almost certainly buggier, since it's an alpha release.
  * The system only runs on Linux/x86. (This isn't for any
    fundamental reason, only because no one has ported it.
    Porting SBCL should be comparable in difficulty to porting CMU CL;
    porting SBCL to an architecture already supported by CMU CL should
    be pretty easy.)
  * The documentation is not as good as CMU CL's. In particular, there
    is no SBCL user manual yet, only a man page and doc strings, so
    if you need user manual information, you have to refer to the
    CMU CL user manual.

Besides the particular shortcomings of version 0.6.0, SBCL will
probably always have some drawbacks compared with CMU CL:
  * SBCL doesn't try to be backwards compatible with most of the
    CMU CL non-ANSI extensions. (However, I have retained the FFI
    extensions, which are the fundamental building blocks for most of
    the other stuff; and I'd be happy to distribute ports of the other
    CMU CL extension packages as contrib/ code if someone else would
    like to maintain them. I just don't want to maintain them myself.)
  * I've been willing to simplify the system even at some cost to
    performance, so SBCL may be slower than CMU CL in some respects.
(E.g.,
    I've removed memory pooling in the compiler, so the SBCL compiler
conses
    more than CMU CL's; and the SBCL READ-SEQUENCE implementation has
fewer
    performance-oriented special cases than CMU CL's (and is hopefully
    less buggy, too:-).)
  * Despite my desire for simplicity, in some ways the SBCL code is
    necessarily more complicated than the CMU CL code, because SBCL
    maintains a clean separation between cross-compilation host and
    target system instead of sharing things opportunistically between
    them. I believe the benefits of this clean separation easily pay
    for the costs, but the costs are noticeable. (Common Lisp is not
    a cross-compiler-friendly language.:-)

As an aside to anyone who looked at the previous, pre-alpha version
(sbcl-0.5.0):
  The bootstrap process in the current version is less of a memory pig
  than in 0.5.0. In 0.6.0, bootstrapping takes on the order of 40 Mb
  through most of the build phase and peaks at a little under 128 Mb.
  The peak usage occurs in the "genesis" phase (static linking, more
  or less), which doesn't stress the virtual memory system very hard, so
  building the system works fine on my old laptop (P133 with 48 Mb of
  RAM and 128 Mb of swap).

SBCL is available at
        http://www.*-*-*.com/
This site maintains mailing lists for SBCL, and SBCL-specific
discussion (e.g. "Can I run SBCL on a non-ELF system?" or "When are
you planning to make a user manual?") probably belongs there instead
of comp.lang.lisp.

  Bill Newman
  PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Fri, 26 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL
Very cool work.  Hopefully this will increase the number of
people working on free CL implementations.

[...]

Quote:
>    Porting SBCL should be comparable in difficulty to porting CMU CL;

Why is this?  Shouldn't it be easier because of the simplified
bootstrapping?  Do you mean that the bootstrapping issues are
insignificant compared to the rest of the port.

Can SBCL be compiled with any CL implementation or does it have
to be compiled with itself?

    Neil



Fri, 26 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL
Centuries ago, Nostradamus foresaw a time when Neil Schemenauer would
say:

Quote:
>Very cool work.  Hopefully this will increase the number of
>people working on free CL implementations.

Perhaps.

If SBCL is an easier port than CMU CL, this may make it of more
interest.  The claim below suggests that this is not the case.

If it is easier to work on than CMU CL, this make it easier for people
to work on it.

Aside from that, if it divides peoples' interests, confusing people as
to whether it is better to work on one or the other, that would *not*
be a good thing.  Similarly, if it means that there are two CL
codebases that need maintaining, that is not too much of an
improvement either.

Quote:

>[...]
>>    Porting SBCL should be comparable in difficulty to porting CMU CL;

>Why is this?  Shouldn't it be easier because of the simplified
>bootstrapping?  Do you mean that the bootstrapping issues are
>insignificant compared to the rest of the port.

>Can SBCL be compiled with any CL implementation or does it have
>to be compiled with itself?

--
"Programming today  is a race  between software engineers  striving to
build bigger and better  idiot-proof programs, and the Universe trying
to  produce  bigger  and  better  idiots.  So  far,  the  Universe  is
winning."  -- Rich Cook



Sun, 28 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL

Quote:

> Aside from that, if it divides peoples' interests, confusing people as
> to whether it is better to work on one or the other, that would *not*
> be a good thing.  Similarly, if it means that there are two CL
> codebases that need maintaining, that is not too much of an
> improvement either.

The way you have written this makes it sound as though you are overall
negative about the existence of the SBCL project.  Is this a correct
summary, and if so do you have similar opinions regarding, say, NetBSD
vs FreeBSD vs OpenBSD?

Personally I think that the two projects have differing objectives and
development styles, and that people will have little trouble deciding
which to contribute to.  I'm sure that code in each will find its way
into the other if it's deemed appropriate.

Quote:
Another writer writes:
> >Can SBCL be compiled with any CL implementation or does it have
> >to be compiled with itself?

SBCL 0.5.0 could be compiled at least with itself and with CMUCL.  I
don't know about 0.6 as I haven't tried it yet, but I believe it to be
a goal that other CLs be able to compile it.

-dan



Sun, 28 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL

Quote:

> I'm working on SBCL,

[...]

I guess you've got your reasons, but...

...WOT NO SOCKETS?!

Surely sockets are becoming more and more important as networking
becomes a bigger and bigger part of computing.  Is this for portability?
Is it possible to improve CMUCL's portability without removing such
major features?

Andrew
http://www.andrewcooke.free-online.co.uk/index.html

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 28 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL


Quote:
> I guess you've got your reasons, but...

> ...WOT NO SOCKETS?!

> Surely sockets are becoming more and more important as networking
> becomes a bigger and bigger part of computing.

I threw most of the non-ANSI stuff overboard both for the practical
reason that I was already overwhelmed with stuff to update and maintain
and for the aesthetic reason that I prefer relatively simple core
systems. As I wrote earlier, since I kept the building blocks for it
(the ALIEN and C-CALL packages), it should be straightforward to put
this sort of stuff back in as extensions if someone is motivated to do
so.

Incidentally, I certainly agree connectivity is important: the
application that I work on most limps along connected to a driver
program through *STANDARD-INPUT* and *STANDARD-OUTPUT*, and it's
sometimes a hassle. But I'm not convinced that sockets in general or the
CMU CL sockets library in particular are so clearly the best solution
(what about CORBA? or a port of Perl's socket interface?) that they
should be a mandatory part of the system. And in any case I'm just not
prepared to try to support more stuff.

Quote:
> Is this for portability?

> Is it possible to improve CMUCL's portability without removing such
> major features?

It didn't have much to do with portability -- sockets exist on every
machine that the system is likely to run on in the foreseeable future.
It's just reducing the maintenance burden and core system size.

  Bill Newman

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 28 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL


Quote:

> > Aside from that, if it divides peoples' interests, confusing people
as
> > to whether it is better to work on one or the other, that would
*not*
> > be a good thing.  Similarly, if it means that there are two CL
> > codebases that need maintaining, that is not too much of an
> > improvement either.

> The way you have written this makes it sound as though you are overall
> negative about the existence of the SBCL project.  Is this a correct
> summary, and if so do you have similar opinions regarding, say, NetBSD
> vs FreeBSD vs OpenBSD?

> Personally I think that the two projects have differing objectives and
> development styles, and that people will have little trouble deciding
> which to contribute to.  I'm sure that code in each will find its way
> into the other if it's deemed appropriate.

Forking has very real drawbacks. I think it makes sense in this case,
but it can certainly be a problem, and I've worried about it.

The existence of SBCL will probably cause some effort to be wasted as
work is duplicated on both branches. This will be bad.

I hope that the existence of SBCL will make it possible to do things
which weren't practical before (because of bootstrapping or other
problems). This will be good.

I also hope that the ease of rebuilding SBCL will attract developers who
would have been turned off by CMU CL. This will be good too.

I think it's reasonable to hope that the good effects will be more
important than the bad ones, but only time will tell.

Quote:
> Another writer writes:
> > >Can SBCL be compiled with any CL implementation or does it have
> > >to be compiled with itself?

> SBCL 0.5.0 could be compiled at least with itself and with CMUCL.  I
> don't know about 0.6 as I haven't tried it yet, but I believe it to be
> a goal that other CLs be able to compile it.

As I wrote in another branch of this thread:
  with CMU CL: yes
  with SBCL itself: yes
  with CLISP: no (because CLISP doesn't have MAKE-LOAD-FORM)
  with other Common Lisp systems: probably, but untested
As far as I know, the only things needed from the host Lisp, besides the
core ANSI functionality, are ASCIIness of characters and
IEEEness of floats. That could be fixed, but without a non-ASCII or
non-IEEE system to test on, I'm not motivated to fix it.

  Bill Newman

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 28 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL
Centuries ago, Nostradamus foresaw a time when Daniel Barlow would say:

Quote:

>> Aside from that, if it divides peoples' interests, confusing people as
>> to whether it is better to work on one or the other, that would *not*
>> be a good thing.  Similarly, if it means that there are two CL
>> codebases that need maintaining, that is not too much of an
>> improvement either.

>The way you have written this makes it sound as though you are overall
>negative about the existence of the SBCL project.  Is this a correct
>summary, and if so do you have similar opinions regarding, say, NetBSD
>vs FreeBSD vs OpenBSD?

>Personally I think that the two projects have differing objectives and
>development styles, and that people will have little trouble deciding
>which to contribute to.  I'm sure that code in each will find its way
>into the other if it's deemed appropriate.

No, I'm not negative, I'm simply wondering why it is useful to have
both SBCL and CMUCL.

I can't usefully distinguish between them at this point, which is the
"problem" I'm trying to resolve.

The (Net|Free|Open)BSD situation unfortunately shows that the
respective communities of developers *prefer* to be separate; enough
flames emerge to show that the separations are not solely on technical
grounds.

It may be that SBCL will prove to be significantly easier to
maintain/port than CMUCL, or that it will, due to *apparent* ease of
participation, attract significant development efforts.  Those would
both be good things, and would be good "excuses" for its existence.

On the other hand, if having SBCL doesn't result in increasing the
number of overall developers working on CL implementations, this is
not an improvement, and could detract from both SBCL and CMUCL.  I
would consider that a "negative" thing, unless it had the simultaneous
sideeffect of SBCL being greatly easy to maintain, thus meaning that
equivalent maintenance requires fewer developers.
--
"... the most important thing in the programming language is the name.
A language will not succeed without a good name.  I have recently
invented a very good name and now I am looking for a suitable
language."  -- D. E. Knuth, 1967



Mon, 29 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL

Quote:

> I can't usefully distinguish between them at this point, which is the
> "problem" I'm trying to resolve.

Well there is at least one useful distinction between them at this
point (in fact there are a few more):  SBCL is vastly more
experimental and fluid than CMUCL, which has it's positive and
negative implications:  As it stands SBCL and it's implementor(s) are
at liberty to diverge from decades-old implementation and interface
decissions, that maintainers of CMUCL would find it hard to do.

This allows SBCL to be cleaned up quite a lot, and by the shaking up
of the code base, a number of benefits might follow.  Or then again
they might not follow.  One doesn't know in advance, so the only
possibility of finding that out is to try it out, since there is no
practical possibility of doing the SBCL project inside the CMUCL
main-branch of development (it would also be totally confusing to
suddenly have two CMUCL's which are quite incompatible).

Quote:
> The (Net|Free|Open)BSD situation unfortunately shows that the
> respective communities of developers *prefer* to be separate; enough
> flames emerge to show that the separations are not solely on technical
> grounds.

But project organization and communities are never about technical but
always about social issues.  There are no "technical" reasons for not
merging all Unix-like OS's into one.  But there are social, economic
and practical reasons for not wanting to do that.

Quote:
> On the other hand, if having SBCL doesn't result in increasing the
> number of overall developers working on CL implementations, this is
> not an improvement, and could detract from both SBCL and CMUCL.  I
> would consider that a "negative" thing, unless it had the simultaneous
> sideeffect of SBCL being greatly easy to maintain, thus meaning that
> equivalent maintenance requires fewer developers.

I don't quite agree with this.  One possible outcome of the SBCL
project might be that the "technology" and work behind SBCL will prove
sufficiently useful that it will be readopted/merged back into CMUCL,
thereby rejuvenating CMUCL and increasing CMUCL developer
productivity.

Or a number of other possible outcomes might ensue.  Let's wait and
see...

Regs, Pierre.

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]



Mon, 29 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL

Quote:



> > I guess you've got your reasons, but...

> > ...WOT NO SOCKETS?!

> > Surely sockets are becoming more and more important as networking
> > becomes a bigger and bigger part of computing.

> I threw most of the non-ANSI stuff overboard both for the practical
> reason that I was already overwhelmed with stuff to update and maintain
> and for the aesthetic reason that I prefer relatively simple core
> systems. As I wrote earlier, since I kept the building blocks for it
> (the ALIEN and C-CALL packages), it should be straightforward to put
> this sort of stuff back in as extensions if someone is motivated to do
> so.

> Incidentally, I certainly agree connectivity is important: the
> application that I work on most limps along connected to a driver
> program through *STANDARD-INPUT* and *STANDARD-OUTPUT*, and it's

Euh.. Can one use ILISP?

Also, can we get COMPILER-LET? Otherwise, someone will just have to define
a macro that does
the same inside the SERIES code.

Thanks,

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

www.csem.ch      www.vrai.com     ligwww.epfl.ch/matomira.html



Tue, 30 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL
        I've just spent a few hours trying to get SBCL to build and
run under FreeBSD 3.4. Not that I've got anything against Linux, but
I'm quite happy with FreeBSD...

        For the lisp runtime "driver", I've stolen FreeBSD-os.[ch] from
the latest CMUCL sources (a couple of patches to FreeBSD-os.c was
required). I also had to patch x86-assem.S to cater for the
fact that FreeBSD 3.x, like Linux, does not prepend an underscore to
external names. I also made a change to genesis.lisp
(lookup-foreign-symbol) for the same reason.

        Using the CMUCL snapshot from 1999-12-06, I can easily get as
far as creating cold-sbcl.core, sbcl.h and sbcl. When I try to run
sbcl with cold-sbcl.core, I get a core dump - not exactly what I'm
looking for :-)

        The core dump seems to appear just after a call to
mmap - I had an idea that this might be because the mmap call resulted
in a zeroing of program text, so I have played around a bit with the
mappings in x86-validate.h. There may be some settings in a lisp file
that has to be modified similarly; hints, anyone?

        Is anybody else working on getting SBCL to work on FreeBSD?

        //Raymond.

--
Raymond Wiker



Wed, 31 Jul 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL
I found the install and setup for Caldera OpenLinux 2.3 to be easy!

Good job.

BTW, would it be a possibility to get SBCL ported to
WIN32 using the Cygnus development tools?

Thanks,
Mark Watson, author, AI hacker :]
www.markwatson.com


Quote:

> I'm working on SBCL,
>    http://sbcl.sourceforge.net/

Sent via Deja.com http://www.deja.com/
Before you buy.


Fri, 02 Aug 2002 03:00:00 GMT  
 SBCL, a new free Common Lisp based on CMU CL

    markw> I found the install and setup for Caldera OpenLinux 2.3 to be easy!
    markw> Good job.

    markw> BTW, would it be a possibility to get SBCL ported to
    markw> WIN32 using the Cygnus development tools?

My understanding is that Cygwin does not support everything that CMUCL
needs.  This includes mmap and access to the processor context on
interrupts.

So SBCL won't really help in getting CMUCL to run on Windows.

Ray



Fri, 02 Aug 2002 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. new free web book on Common Lisp

2. Old (CLtL1) CMU CL (or other lisp)

3. New Common Lisp, Lisp-to-C translation, Lisp library for C

4. New CMU CL distribution hosts

5. REPOST: JOB: Research Programmer (Common Lisp) -- Robotics Institute CMU

6. Running CL-HTTP w/ CMU-CL

7. Multiple threads in CMU Common Lisp?

8. CMU Common Lisp: Detecting EOF on a wire

9. random in CMU Common LISP

10. Measuring time in CMU Common Lisp

11. CMU Common Lisp for Linux?

12. CMU Common Lisp for Linux wanted

 

 
Powered by phpBB® Forum Software