Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Peter Graves <peter <at> armedbear.org>
Subject: Re: PATCH: DESTRUCTURING-BIND sets up a block
Newsgroups: gmane.editors.j.devel
Date: Sunday 18th February 2007 13:55:02 UTC (over 10 years ago)
On Sat, 17 Feb 2007 at 13:45:12 +0100, Andras Simon wrote:
> > what is XCL?
> > i'm just currious if it's some new Common Lisp implementation or maybe
ABCL
> > packaging.. google didn't find anything relevant on it..
>
> It did for me: http://tunes.org/~nef/logs/lisp/06.06.17
>
> But, of course, I'd also like to know more... I'm especially curious
> about how it affects the future of ABCL.

XCL is a new, native-code CL implementation that features a kernel
written in a very restricted subset of C++ and an optimizing compiler,
written in Lisp, with backends for x86 and x86-64. It runs on Linux and
Windows, and it probably could be made to work on Intel OS X, but I
don't have a Mac to try it on.

The kernel is mostly done.

The compiler is much less done, but it's done enough that it runs a
subset of ansi-tests in compiled mode with 55 failures out of 15085
tests. (Like ABCL's compiler in the early days, XCL's compiler falls
back gracefully to the interpreter when it encounters code that it
doesn't know how to compile yet.)

The last time I ran the full test suite, there were something like 800
failures (out of ~21000 tests), mostly in areas where the library code
isn't there yet or is very new (currently the printer is the long pole
in that tent). Recently I've been working on file compilation, which
has left things a little more broken than usual; I don't think I can
run the full suite with my current tree.

XCL supports threads on both Linux and Windows, and in principle the
compiler is re-entrant.

On code that it knows how to compile, XCL is reasonably fast (on rare
occasions, even faster than SBCL), but there's a lot of code it can't
compile yet...

I don't think XCL is going to have much short-term effect on the future
of ABCL one way or the other.

At some point it will probably make sense to have XCL and ABCL support
the same API in areas outside the standard like sockets and threads and
fancy streams.

ABCL needs a new CLOS, and eventually XCL will have one (it's not very
far along at this point), so maybe that's another area where synergy
will be possible in the future.

-Peter



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
 
CD: 3ms