[Openmcl-devel] New binaries (including PPC64 binaries) available in testing directory

[Gary Byers]

There are new (050616) binaries in ftp://clozure.com/pub/testing.  Aside
from the usual ppccl-image and dppccl-image archives for 32-bit Linux
and OSX/Darwin, there's also a preliminary dppccl64-image archive containing
a port of OpenMCL to the 64-bit environment provided by OSX 10.4 on G5
processors.

I'll try to write some more detailed release notes later today.  Briefly:

  - this is all based on the bleeding-edge (ccl-0.14-dev) source tree
  - this requires OSX 10.4 to build and (additionally) a G5 to run
  - there's a set of 64-bit interface files in the testing directory
    (in openmcl-darwin64-interfaces-YYMMDD.tar.gz).  Note that Apple
    doesn't provide PPC64 versions of GUI libraries under OSX 10.4, so
    the darwin64 interfaces only contain a "libc" directory.
  - there's an "openmcl64" shell script
  - the kernel ("dppccl64") can be built from the "ccl:lisp-kernel;darwin64"
    directory.
  - FASL files have the extension .d64fsl
  - there are a handful of low-level math functions (I think 4 of them, at
    last count) that are currently unimplemented (you'll get some warnings
    if you do (XLOAD-LEVEL-0).  (There've been lots of low-level lisp and
    LAP functions that needed tweaking and/or reimplementation to be less
    sensitive to word-size and other issues: these 4 are the ones that I
    haven't gotten to yet; I'll try to get to them soon.)
  - there may be other functions that -should- be conditionalized for
    PPC64 but either haven't been or have been conditionalized incorrectly
    in some way.  In general, this means that there can be weird and
    surprising bugs in harmless-looking code.  (I've caught a lot of these
    and a lot of things -do- work, but I'm sure that some bugs remain.)
  - The 64-bit port compiles itself and seems to do so cleanly and correctly
    (with the exception of the undefined-function warnings noted above.)
    That puts fairly significant stress on the GC, but it's only been able
    to survive that stress for a few days (and has only been able to survive
    the EGC for a few hours.  It sort of follows that you would not want to
    use this in a production environment and should not be shocked if you
    run into some weird GC-related misbehavior.
  - ROOM will tell you that something like ~125 GB are "reserved for heap
    expansion".  You'll probably find that trying to use more (virtual)
    memory than you have won't work too well, and if you try to use
    significantly more virtual memory than the amount of physical memory
    you have (more than a small constant factor) you'll suffer severe
    performance degradation.  In PPC32, saying:

? (make-string (ash 1 40))

    will fail quickly, since the implementation doesn't allow any array
    to have 2^24 or more elements.  In the PPC64, that -might- try very
    hard to make an array with a trillion or so elements, and might not
    fail gracefully when it finds that there (probably) isn't enough
    virtual memory to support creating a string of that size.

More information/notes later; I hope that this will be of interest and
(soon) of use.