[Openmcl-devel] OpenMCL future

[Gary Byers]

On Wed, 11 Sep 2002, Christophe Rhodes wrote:

> On Fri, Sep 06, 2002 at 09:21:44PM +0200, Rainer Joswig wrote:
>
> > - CLIM (the real CLIM, not FreeCLIM) based on Cocoa/Quartz
>
> As far as I am aware, "FreeCLIM" aka "McCLIM" is an implementation of
> the CLIM specification... what do you mean by "real" here?

I think that there was another effort to develop a FreeCLIM a few years
ago; I remember it as being related to a project to create a Lisp-based
OS.

As far as I know, Mike McDonald's McCLIM
<http://www.mikemac.com/mikemac/McCLIM/index.html> is a separate effort
that's a lot farther along than the old project ever got.

John Wiseman made some effort to port this to OpenMCL a few months ago;
he reported some success (<http://lemonodor.com/archives/000160.html>),
but was hampered by OpenMCL's lack of MOP support.

>
> > - investigation where Altivec could be used to speed up the
> >   Lisp kernel or compiled Lisp code
>
> I've been interested in this (well, coming from sbcl/x86-land, the
> analogous question of how SSE can help SBCL :-), and the conclusion that
> I came to was that first the compiler needs to understand loops
> properly. I don't know offhand what understanding the OpenMCL compiler
> has; the CMUCL/SBCL "Python" compiler doesn't do very much at all with
> loops, sadly, so it might be quite some work.

One other complicating factor has to do with AltiVec's alignment constraints:
it prefers data to be aligned on 128-bit boundaries, though there's a
"vector permute" operation that allows it to deal with mis-aligned data.

Like most 32-bit lisps, OpenMCL only guarantees 64-bit alignment of heap
allocated data (so something's 128-bit aligned about half the time, on
average.)  The introduction of preemptively scheduled threads will mean
that a GC could change the address (and alignment) of an object at
virtually any time, which makes it hard to use AltiVec instructions on
general, heap-allocated data.

There may be several ways around this; one attractive appproach is to
wait until the problem disappears (PPC64, etc.), but that solution may
not be entirely satisfactory.

>
> One thing I would be interested in is a slightly nebulous cooperation
> between at the very least the "free" implementors; for instance, in the
> sphere of extensions, it may be that interfaces can sensibly be shared
> across implementations. As a concrete example of this, consider Unicode
> support; work is ongoing to add Unicode to CMUCL; SBCL will probably
> acquire support eventually; Rainer wants support in OpenMCL; CLISP has
> it already, as do ACL and SCL; we might be able to save ourselves (and
> our users, if that's a distinct set) some pain if we hash out the issues
> involved, even if we end up not being 100% compatible in the end...
>

A few weeks ago, a colleague and I got ourselves fairly psyched about
this sort of collaborative effort. I still think that it's a good idea,
and wonder how best to proceed.

CLOCC makes some effort to define a portable extension layer; though
it's probably not as broad as one might like, it seems to me to be
mostly at about the right depth.  I wonder if some or all of it would
be a good starting point ?

I'm certainly interested in exploring this further, and if we get it
off the ground, to committing time and effort to the process.  I think
that it's worth remembering that language design is a hard problem, and
even if we keep our aims fairly conservative it can be a time-consuming
process (see X3J13 and similar efforts.)

I think that it would be extremely desirable for implementors to
commit to providing this "common portability layer" as part of their
implementations (either builtin to the initial image or easily REQUIREd
in some fairly standard way.)


> Cheers,
>
> Christophe
> --
> Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
> http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar
> (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
> (set-dispatch-macro-character #\! #\$ #'pling-dollar)
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel