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 segregation99% 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 "non-troublesome" code than I'd been spending tracking down bugs caused by the other 1%.
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 #p"FOO" and #p"foo" 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")
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.
Darwin/MacOS X distinguishes between "shared libraries" and
"bundles" 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 - "bundles/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 "bundles"; 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.