SBCL and/or CMUCL 
Author Message
 SBCL and/or CMUCL

For some time now, I have been following SBCL and the attempts to make
it more "buildable" and clean.

What I have been looking for are signs that SBCL is moving towards
becoming a self-hosting Common Lisp.

By self-hosting I mean a system that could, once some kernel code is
executable on a target platform, build itself upwards to selectable or
programmable implementation levels. There is the old saying that Lisp
can be defined in itself, i.e. in Lisp. The question is: Can SBCL, or
CMUCL ever be expected to become buildable without using a full Common
Lisp?

Daniel Barlow mentioned in an earlier thread that a lot could be said
about the VOPs. This has lead me to some questions of a general nature,
which is why I put them in this n.g.

- How "tangled" is the CMCUCL/SBCL internal code really?

- Can interdependencies between different parts of the
  code be reduced with a reasonable effort, whatever
  reasonable means?

- Which of the facilities in the underlying operating system are
  unconditionally needed, other than file- and terminal I/O?

- Is some kind of layering possible (of course it is). Are there
  any thoughts about doing it?

Lars



Wed, 25 Feb 2004 17:57:27 GMT  
 SBCL and/or CMUCL

Quote:

> For some time now, I have been following SBCL and the attempts to make
> it more "buildable" and clean.

> What I have been looking for are signs that SBCL is moving towards
> becoming a self-hosting Common Lisp.

> By self-hosting I mean a system that could, once some kernel code is
> executable on a target platform, build itself upwards to selectable or
> programmable implementation levels. There is the old saying that Lisp
> can be defined in itself, i.e. in Lisp. The question is: Can SBCL, or
> CMUCL ever be expected to become buildable without using a full Common
> Lisp?

What do you expect the kernel code to be written in?

Cross compilation has been a well-respected strategy for portings systems
forever.  Nowadays, with the canonical reference platform (x86 Linux)
almost free, it's more viable than ever.

People who hack on Common Lisp systems actually like writing in Common
Lisp, so the attraction of writing large parts of the system in some
primitive Lisp or (horrors) C is somewhat lacking.

Quote:

> - How "tangled" is the CMCUCL/SBCL internal code really?

I can't speak for SBCL, but the CMUCL compiler is pretty tangled.  I used
to blithely assert that CMUCL was easy to rebuild; after making a
significant modification to CMUCL, I'm a bit less sanguine about it.

One of these days I'll give SBCL a shot.

Quote:
> - Which of the facilities in the underlying operating system are
>   unconditionally needed, other than file- and terminal I/O?

> - Is some kind of layering possible (of course it is). Are there
>   any thoughts about doing it?

There is layering in CMUCL between a kernel, that has just enough to load
FASL files (a significant amount of the system, actually) and all the
rest, including the compiler and PCL.  The kernel could probably be made
smaller.

Tim



Thu, 26 Feb 2004 03:06:11 GMT  
 SBCL and/or CMUCL

    Lars> By self-hosting I mean a system that could, once some kernel code is
    Lars> executable on a target platform, build itself upwards to selectable or
    Lars> programmable implementation levels. There is the old saying that Lisp
    Lars> can be defined in itself, i.e. in Lisp. The question is: Can SBCL, or
    Lars> CMUCL ever be expected to become buildable without using a full Common
    Lars> Lisp?

I don't think so.  If you look at the source code, there's a directory
of C files that basically implements the loading of a core file,
signal handlers, mmap, gc, some allocators.  That's about it.
Everything else is in lisp.  You need a lisp to build the rest.  I
suppose you could use the byte code compiler and compile everything to
byte codes and add a bunch of C code to interpret the byte codes.
Haven't heard of anyone trying to do that.  This might be the easiest
way to make it self-hosting.  But then you'd need something to compile
the lisp code to byte codes....

    Lars> - Which of the facilities in the underlying operating system are
    Lars>   unconditionally needed, other than file- and terminal I/O?

CMUCL needs signal handlers, of course.  Another thing is being able
to mmap a file at fixed known addresses.  (CMUCL needs this because it
assumes that T, NIL and other known symbols are at fixed locations.
The compiled code makes use of this.  It may be possible to remove
this restriction.)

Ray



Thu, 26 Feb 2004 03:26:33 GMT  
 SBCL and/or CMUCL


Quote:

> > For some time now, I have been following SBCL and the attempts to make
> > it more "buildable" and clean.

> > What I have been looking for are signs that SBCL is moving towards
> > becoming a self-hosting Common Lisp.

> > By self-hosting I mean a system that could, once some kernel code is
> > executable on a target platform, build itself upwards to selectable or
> > programmable implementation levels. There is the old saying that Lisp
> > can be defined in itself, i.e. in Lisp. The question is: Can SBCL, or
> > CMUCL ever be expected to become buildable without using a full Common
> > Lisp?

> What do you expect the kernel code to be written in?

First, I was sloppy in using the word "kernel". Perhaps "level 0
bootstrap engine" will do?

It would depend on the processing tasks of this engine, the nature of
the level 1 source code which it must process, and the target building
strategy, eg how portable should the bootstrap engine(s) be?

So I'd say:

 -  Use assembler as little as possible
  - Use Lisp and some VOPs  without sacrificing clarity too much

Sorry, I know I am evading the question, but there is no simple answer.

Quote:
> Cross compilation has been a well-respected strategy for portings systems
> forever.  Nowadays, with the canonical reference platform (x86 Linux)
> almost free, it's more viable than ever.

Yes, but I'm thinking about a minimum system level where self
compilation can start.

Quote:
> People who hack on Common Lisp systems actually like writing in Common
> Lisp, so the attraction of writing large parts of the system in some
> primitive Lisp or (horrors) C is somewhat lacking.

I would avoid C for this task.

But whether you call it "primitive" Lisp, or Micro Lisp, or VOPs, does
not alter the fact that you will need it as a fundament for Common Lisp.

Quote:
> I can't speak for SBCL, but the CMUCL compiler is pretty tangled.  I used
> to blithely assert that CMUCL was easy to rebuild; after making a
> significant modification to CMUCL, I'm a bit less sanguine about it.

Saying that CMUCL grew "organically" or  was "designed by accident"
would be unkind, but it would explain the tangle.

Quote:
> There is layering in CMUCL between a kernel, that has just enough to load
> FASL files (a significant amount of the system, actually) and all the
> rest, including the compiler and PCL.  The kernel could probably be made
> smaller.

Then I think that some serious spec work is needed first.

Lars



Thu, 26 Feb 2004 15:06:15 GMT  
 SBCL and/or CMUCL

Quote:

> Daniel Barlow mentioned in an earlier thread that a lot could be said
> about the VOPs. This has lead me to some questions of a general nature,
> which is why I put them in this n.g.

These questions seem to be the free software equivalent of what for a
proprietary Lisp would trigger the response "ask your vendor".

The equivalent for SBCL is "try posting this to the sbcl-devel list"
(sbcl-devel at lists dot sourceforge dot net).  I don't know how many
of the sbcl developers read usenet, but we prefer that questions of
this kind go to the mailing list, so that the list archive can pick up
and preserve any useful answers.

Incidentally, someone already asked about VOPs recently (in response
to the same thread as you're thinking of), so the list arfchive
already includes my brain dump on the subject.

-dan

--

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources



Thu, 26 Feb 2004 08:58:32 GMT  
 SBCL and/or CMUCL

Quote:
> These questions seem to be the free software equivalent of what for a
> proprietary Lisp would trigger the response "ask your vendor".

> The equivalent for SBCL is "try posting this to the sbcl-devel list"
> (sbcl-devel at lists dot sourceforge dot net).  I don't know how many
> of the sbcl developers read usenet, but we prefer that questions of
> this kind go to the mailing list, so that the list archive can pick up
> and preserve any useful answers.

 ... some of the people in the SBCL team would _not_ read c.l.l? :-((

Any questions about SBCL development should of course be directed to the
team. I think, however, that others in this n.g might find a quiet,
general conversation on this topic worthwile.

Quote:
> Incidentally, someone already asked about VOPs recently (in response
> to the same thread as you're thinking of), so the list arfchive
> already includes my brain dump on the subject.

Thanks, I'll have a look at it.

Lars



Thu, 26 Feb 2004 20:35:10 GMT  
 SBCL and/or CMUCL

Quote:

> For some time now, I have been following SBCL and the attempts to make
> it more "buildable" and clean.

> What I have been looking for are signs that SBCL is moving towards
> becoming a self-hosting Common Lisp.

> By self-hosting I mean a system that could, once some kernel code is
> executable on a target platform, build itself upwards to selectable or
> programmable implementation levels. There is the old saying that Lisp
> can be defined in itself, i.e. in Lisp. The question is: Can SBCL, or
> CMUCL ever be expected to become buildable without using a full Common
> Lisp?

I'm not sure I entirely understand what you mean by "self-hosting",
but I think it's not a good term for what you're trying to express.
CMUCL is *quite* self-hosting -- it needs itself to build itself.

Why would you want to write a large complex system (a CL system for
example) in something other than full Common Lisp?  Do you mean C or
C++ or a subset of CL?  And would you really want to build a Lisp
system in that language, when you could have all of CL?

If the point is to be able to install SBCL by unpacking some sources
and typing "./configure && make && make check && make install" like a
lot of unix software, it's nearing that ability.  The above line is
how you install CLISP, and SBCL is moving in the direction of being
able to be built by CLISP.  Part of the reason for the fork was to
make SBCL a system that could be built by any CL.  With one of those
able to be built using just a C compiler...

Quote:
> Daniel Barlow mentioned in an earlier thread that a lot could be said
> about the VOPs. This has lead me to some questions of a general nature,
> which is why I put them in this n.g.

I asked about this on the sbcl-help list and he responded in some
detail, which you may be interested in:
  <http://www.geocrawler.com/archives/3/1664/2001/8/0/6521166/>

Quote:
> - How "tangled" is the CMCUCL/SBCL internal code really?

> - Can interdependencies between different parts of the
>   code be reduced with a reasonable effort, whatever
>   reasonable means?

These questions are different form "can it be made to not need a full
CL system?".  This more or less asks if it can be built from a
different CL system; which as I already mentioned is a goal of SBCL
(but not CMUCL).

[...]

Quote:
> - Is some kind of layering possible (of course it is). Are there
>   any thoughts about doing it?

What kind of layering do you have in mind?  There's already a
kernel/rest layering, but perhaps you're thinking more of something
along the lines of a kernel in C, a CL0 needing only the kernel, a CL1
needing only CL0, and CLOS needing only CL1?  This might be an
interesting approach for a new implementation, but I think
retrofitting an existing implementation to this model would be a
serious pain.  SBCL has done a lot of work towards identifying and
managing interdependencies in the part written in CL, though.


Fri, 27 Feb 2004 05:46:07 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. more cmucl & sbcl questions

2. SBCL vs. CMUCL

3. CMUCL or SBCL on the Mac

4. AMD64 port for SBCL

5. SBCL 0.8alpha: first prerelease

6. SBCL port to NetBSD

7. UFFI and CLSQL now support SBCL & OpenMCL

8. SBCL, a new free Common Lisp based on CMU CL

9. Calling SBCL from C with array arguments

10. SBCL core dumps?

11. CMUCL performance in the Shootout

12. CMUCL: concurrent programming questions

 

 
Powered by phpBB® Forum Software