Darwin PDF Print E-mail
Written by Rizki Noor Hidayat Wijayaź   
Tuesday, 30 November 1999

Using OpenMCL under Darwin and MacOS X

Most of the documentation and whatever experience you may have in using OpenMCL under LinuxPPC should apply to using it under Darwin/ MacOS X. There are some differences between the platforms, and these differences are sometimes exposed in the implementation.

FASL file segregation

99% of the compiled lisp code in the two implementations is identical. Since both implementations target the PowerPC, this shouldn t be too surprising.

The other 1% - code which deals with foreign functions or data or which deals directly with the operating system - is very different but superficially similar. The effects of running such code compiled for the wrong platform range for harmless to catastrophic.

During bootstrapping, the 1% proved troublesome enough that it seemed wise to strictly separate the two implementations. FASL have different file types (.dfsl for Darwin, .pfsl for LinuxPPC) and contain different identifying information; it s not possible to successfully load FASL files compiled for one implementation into the other.

I think that it s wise to maintain this distinction; I spent a lot less time recompiling the 99% of on-troublesome code than I d been spending tracking down bugs caused by the other 1%.

File-system case

Darwin and MacOS X use HFS+ file systems by default; HFS+ file systems are case-insensitive. Most of OpenMCL s filesystem and pathname code assumes that the underlying filesystem is case-sensitive; this assumption extends to functions like EQUAL, which assumes that #pFOO and #pfoo denote different, un-EQUAL filenames. Since Darwin/MacOS X can also use UFS and NFS filesystems, the opposite assumption would be no more correct than the one that s currently made.

Whatever the best solution to this problem turns out to be, there are some practical considerations. Doing:

? (save-application DPPCCL)

has the unfortunate side-effect of trying to overwrite the Darwin OpenMCL kernel, dppccl, on a case-insensitive filesystem. To work around this, the Darwin OpenMCL kernel expects the default heap image file name to be the kernel s own filename with the string .image appended, so the idiom would be:

? (save-application dppccl.image)

Single-precision trig & transcendental functions

Despite what Darwin s man pages say, its math library doen t implement single-precision variants of the transcendental and trig functions (#_sinf, #_atanf, etc.) OpenMCL works around this by coercing single-precision args to double-precision, calling the double-precision version of the math library function, and coercing the result back to a SINGLE-FLOAT. These steps can introduce rounding errors (and potentially overflow conditions) that might not be present or as severe if true 32-bit variants were available.

Shared libraries

Darwin/MacOS X distinguishes between shared libraries and undles or extensions; Linux doesn t. In Darwin, shared libraries have the file type dyld : the expectation is that this class of file is linked against when executable files are created and loaded by the OS when the executable is launched. The latter class - undles/extensions - are expected to be loaded into and unloaded from a running application, via a mechanism like the one used by OpenMCL s OPEN-SHARED-LIBRARY function.

OpenMCL wants to treat all shared libs as if they were undles; this is presumably possible, but none of it s implemented under OpenMCL 0.10. Ideally, whatever gets implemented will hide the distinction as much as possible, but it may not be possible to hide it completely.

[download, 12 MB]

Last Updated ( Tuesday, 03 April 2007 )