AMD64 Linux (64 bit)
The 64 bit AMD64 port is built for RedHat Enterprise Linux 4, Fedora Core 7 Linux, and Debian 4.0 Etch Linux, and should work with other compatible Linux based operating systems.
The port supports 80 bit extended precision floating point numbers via the Common Lisp 'long-float type. Double and single precision floating point numbers exploit the SSE extension which provides 16 floating pointer registers in 64 bit mode.
SCL is intended to be installed in the directory: /opt/scl/. If installed elsewhere then the location of the lisp core file will need to be specified on the command line or the SCLLIB environment variable set to the directory containing the lisp core file.
When compiling foreign C code to be loaded into SCL, define _REENTRANT so that the code is built for thread safety, such as thread safe errno handling.
Foreign code may be compiled into a shared object to speed the loading of the object, see ext:load-dynamic-object. The code should be compiled to be position independent, and the shared object must resolve all dependent libraries. Below is an example of compiling the C code in the file tst.c into a shared object that may be loaded by ext:load-dynamic-object where the shared object uses a library named libmylib.
cc -fPIC -D_REENTRANT -c tst.c
ld -G -o tst.so tst.o -L/mylibs -lmylib -lc
Character encoding conversion.
For character format converstion, between the internal UCS-2 format, the glibc library iconv function is used.
The AMD64 port uses a conservative garbage collector. Objects that might otherwise be garbage may be kept alive due to the conservative nature of the garbage collector.
The control stack and the number stack are shared on the AMD64 port.
Up to 224G bytes of memory may be allocated to the lisp heap. The default size is 512MB, which may be overridden using the command line option -dynamic-space-size followed by the size in MBytes.
The Linux 2.6.13 kernel broke the 'madvise' system function used by SCL. The SCL 1.2.9 release includes a work-around for the issue but this may reduce performance. The issue has been corrected in the Linux 2.6.14 kernel.
Linux 2.6.16, 2.6.17, and 2.6.18 kernels can corrupt the processor floating point unit state causing incorrect program execution. A workaround for the SCL is not available but the issue is corrected in the Linux 2.6.19 kernel or a patch is available from Scieneer.
Tracing and breakpoints are not thread safe but should be fine so long as only a single thread touches the code with a breakpoint.