ted@nmsu.edu (Ted Dunning) (04/10/91)
what is the current state of the python compiler from cmu? in particular, is it publically available, and what systems does it target?
ram+@cs.cmu.edu (Rob MacLachlan) (04/11/91)
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 (ram@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
ted@nmsu.edu (Ted Dunning) (04/11/91)
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?