[Openmcl-devel] OpenMCL for Linux x86-64 available for testing

[Gary Byers]

A version of OpenMCL for Linux X86-64 systems is now available for
testing at:

<ftp://clozure.com/pub/testing/openmcl-linuxx8664-all-1.1-pre060502.tar.gz>

or

<http://openmcl.clozure.com/FTP/testing/openmcl-linuxx8664-all-1.1-pre060502.tar.gz>

That archive's self-contained (containes sources, lisp kernel, heap
image, and a somewhat spartan set of interfaces.)

The testing directory also contains the following README file:

--------------------------------------------------------------
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 

<ftp://clozure.com/pub/testing/openmcl-linuxx8664-interfaces-060410.tar.gz>

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.)