Welcome to OpenMCL Version 1.1-pre-060503 (Alpha: LinuxX8664)! - implement #'CCL::%FF-CALL - fix compiler's handling of :SIGNED-DOUBLEWORD (aka :LONG) arguments if compiled %FF-CALL. - unconditionalize CCL::FRAME-SUPPLIED-ARGS and make it work (somewhat) on x8664. - provide a means for SWANK to access the names and values of closed-over variables in a closure (it's not safe to use CCL::%SVREF on functions on x8664. - fix a kernel bug which led to stack misalignment of signal contexts in some cases. ------------------------------------------------------------------------------ Welcome to OpenMCL Version 1.1-pre-060502 (Alpha: LinuxX8664)! What's in the archive ? The archive contains a Linux X86-64 kernel (lx86cl64), a heap image (LX86CL64), OpenMCL sources from the bleeding-edge tree as of 060502, and interface .cdb files (for :libc only.) (There's no good reason for not including interfaces for other things - like X11, GTK/GNOME, etc.; I just haven't built them yet.) Note that the file contains -exactly- the same interfaces as are contained in the full atchive, and that there's no reason to download that file separately. ccl/scripts/openmcl64 contains a shell script which can be customized and installed in the usual way. What platforms are supported ? This is intended to run on x86-64 hardware (AMD Opteron/Athlon64/Turion64 etc, as well as Intel machines that offer what Intel calls "EM64T" extensions; note that this does -not- include currently shipping Intel-based Macintoshes) under "fairly recent" Linux distributions for x86-64. (Note that this means that the Linux kernel must provide support for running 64-bit binaries and that the distribution must offer 64-bit libraries, perhaps as well as 32-bit x86 libraries.) Most major Linux distributions either offer released x86-64 enabled versions or have such versions under development and available for testing and early adoption. The lisp kernel was built on a fairly up-to-date Fedora Core 5 system. The executable file may claim to need more recent versions of libraries than it actually does need. If you encounter this situation, please report it as a bug; the simplest workaround is to just recompile the lisp kernel on your system (cd ccl/lisp-kernel/linuxx8664 ; make). The lisp depends on NPTL support (it might accidentally work with older thread libraries, but I wouldn't want to put much effort into ensuring that), thread-local-storage support in the toolchain and libraries, and a fairly recent 2.6.x Linux kernel. I do not know of any x86-64 Linux distributions which don't provide these features. What works and what doesn't ? Most CL things -should- work (if you find things that don't, please report them as bugs.) The GCL test suite reports some failures (mostly involving things like (= (FLOAT (RATIONAL X)) X) not being true for some SINGLE-FLOAT values of X) that don't occur on PPC. These cases -may- be bugs in FLOAT or RATIONAL, -may- be bugs elsewhere, or may not be bugs at all; this requires further investigation. Floating-point exceptions should be signaled reliably, but ARITHMETIC-ERRORs will often report their OPERATION as "unknown" and their OPERANDS as (). Backtrace has difficulty finding the current values of arguments that're maintained in callee-save non-volatile registers. "Purification" (the process of copying objects that're presumed to be so long-lived as to be considered permanent to static or read-only memory) doesn't work at all (a warning to that effect is generated when the lisp kernel is compiled.) This means that the GC sometimes has to spend time looking at stuff that is unlikely to ever become garbage (probably at least half of the contents of the initial memory image), and it's certainly desirable that purification be made to work soon. What needs more testing ? The short answer is probably "practically everything". The system has been able to compile itself for several weeks (and has sometimes done little else -but- compile itself), so some things have gotten some fairly heavy exercise and other things have gotten none. I don't think that I've done any testing of SOCKETS functionality. (This is all mostly just a wrapper around some OS system calls and some fairly simple data structures, but there's certainly the possibility of some stupidity there.) The FFI seems to be able to do simple FF-CALLS and callbacks; the X86-64 ABI seems to sometimes pass structures by value (somewhat similar to the way that this is done on DarwinPPC), but this isn't handled at all. It may not be too hard to run into other things that are incomplete, rough around the edges, or totally broken. I think that at this point the x8664 port is generally stable enough to allow one to do useful things, but there may still be more flakiness (weird errors, GC bugs) than one would want to see. Please report any of this sort of thing that you encounter (especially if you can find reproducible cases.)