Basically, the answer is that CMU CL sources are available via anonymous
FTP, but that you won't be able to use them without significant effort and
some help from us.
You mentioned a while ago on the net that CMU Common Lisp is available
through "the Mach distribution channels". We have the appropriate
licenses, access to the CMU Mach 3.0 source tree, etc. here; is
getting CMU Common Lisp then as simple as sup ing it over?
I had to check out what the situation was with the Mach people. It turns
out that the situation is not good, but mainly on the Mach side. We will
are ready to distribute to non-CMU users, and can set up SUP (or anonymous
FTP) access.
But we only run on the Decstation 3100, Decstation 5000 and Sparcstation
(probably other SPARC boxes too.) My understanding from the Mach people is
that Mach for these machines is not being distributed (although it is
available at CMU.) The problems are both legality and lack of manpower.
CMU CL should also run (or be easily modified to run) under OSF Unix. This
has been released for the Decstation 3100, and should be available to
university users for a nominal fee ($200?).
Our main dependency is on Mach VM primitives for file mapping, and
copy-on-write and demand-zero paging. There are two main areas of problems
that I see:
1] We use the mach file mapping primitives to map in the Lisp image (which
is in our own format, instead of a standard unix executable.) I
believe that the SUNOS "mmap" syscall provides similar capabilities,
but there will be some problems because Mach's copy-on-write allows us
to be rather lazy about determining what part of the core image is
writable. I believe that when you map a file under SUNOS, it may
allocate paging space for all the data at map time. This is a lose,
and must be worked around somehow. The truly read-only data must be
segregated and somehow mapped more efficiently (either with the
appropriate map call, or my making it part of the text segment.)
2] We make use demand-zero paging and a guard page to implement memory
allocation. Our current mechanism assumes that you can read the
registers on a protection violation signal, modify them, and proceed.
On machines where this is impossible (68k?), you would need to change
to an explicit allocation-end pointer and bounds check. Note that this
will change in our generational GC system which is currently under
development. The GGC system will probably have different portability
constraints, and in developing it, our main concern is good performance
under Mach, rather than maximum portability. If GGC turns out too
nonportable, then we will continue support for stop-and-copy GC.
Most of the VM management is done in C code, so you don't need to be a Lisp
compiler wizard to do most of the work. For new compiler hooks, we will
give you any help you need.
Porting to a system V Unix would have additional problems due to our use of
sockets, PTYS, etc. But we have actually already ported to a system C
system (IBM AIX) once, so it is doable.
We are eager to work together with people on the net to get ports up. If
necessary, we may be able to get implementors accounts on CMU machines for
bootstrapping.
Rob
p.s. Here is a general source availability notice:
________________________________________________________________
Thank you for your expression of interest in CMU Common Lisp and the Python
compiler. Here is some information about FTP access, with some additional
information appended on the end. We are not yet encouraging people outside of
CMU use CMU CL; sources are being made available purely to the technically
curious and to potential implementors.
In addition to the documentation pointers below, the CMU CL documentation
is also available as tech reports:
Hemlock Command Implementor's Manual: CMU-CS-89-134-R1
Hemlock User's Manual: CMU-CS-89-133-R1
CMU Common Lisp User's Manual: CMU-CS-91-108 (hot off the press)
All of our files are in the AFS file system. You can use anonymous ftp to any
CMU machine as a gateway into AFS. Here are some suggested machines:
a.gp.cs.cmu.edu
b.gp.cs.cmu.edu
lisp-rt1.slisp.cs.cmu.edu
lisp-rt2.slisp.cs.cmu.edu
Log in with the user "anonymous" and your real userid as password. Due to
the way anonymous FTP access control is done, it is important to "cd" to the
source directory with a single command, and then do a "get" operation. If
you have any trouble with FTP access, please let me (ยทยทยท@cs.cmu.edu) know.
This is our user documentation in postscript format, 180 pages (definitely
prints on LPS40, quite possibly laserwriter):
/afs/cs/project/clisp/new-compiler/scribe/cmu-user/cmu-user.ps
This is user documentation for our editor, in also postscript format:
/afs/cs/project/clisp/new-compiler/scribe/hem/user/user.ps (124 pages)
/afs/cs/project/clisp/new-compiler/scribe/hem/cim/cim.ps (96 pages)
These are my internal compiler design notes. Be warned that they are somewhat
out of date, although this caveat mainly applies to the back-end.
/afs/cs/project/clisp/new-compiler/ram/work/design.txt
Totally machine-independent compiler code:
/afs/cs/project/clisp/new-compiler/pmax_mach/alpha/compiler/*.lisp
See especially node.lisp and ir1tran.lisp for the front end. vop.lisp,
vmdef.lisp and ir2tran.lisp for the back end.
Stuff that is dependent on our choice of object format, but not
particularly machine-dependent:
/afs/cs/project/clisp/new-compiler/pmax_mach/alpha/compiler/generic/*.lisp
Compiler back-end for the PMAX and SPARC:
/afs/cs/project/clisp/new-compiler/pmax_mach/alpha/compiler/mips/*.lisp
/afs/cs/project/clisp/new-compiler/sun4_mach/alpha/compiler/sparc/*.lisp
is anyone interested in cooperating on moving cmu common lisp (and
python) to sunos?
i have been corresponding with rob maclachlan, and the technical
difficulties seem to be relatively straightforward (mmap semantics
look close enough, and the change to an explicit bounds check should
be straightforward).
is anyone interested in helping?