[Openmcl-devel] 32-bit x86 port update

[Chun Tian (binghe)]

Hi,

By the way, can (require "COCOA") works on 32-bit x86 port now? Are  
there cdb files for this branch?

--binghe


> Here is a status update on the 32-bit x86 port.
>
> There's been some good progress since the last status message I sent
> out about six or seven weeks ago.
>
> The lisp (I think it's fair to call it a lisp now) can self-host.  In
> other words, it compiles itself now.  I very rarely have any occasion
> to cross-compile it any more.
>
> The GC works.  I'm chasing a heap corruption bug or two, but I think
> it's unlikely that the corruption is the GC's fault.  (One of the bits
> that can be set in ccl::*gc-event-status-bits* turns on heap integrity
> checking in the GC.  This causes the GC to check the heap before and
> after it does its thing.  So far, the heap corruption has always been
> reported in the pre-gc heap integrity check.)
>
> You can now use SLIME (which implies that basic threading is working,
> though I suspect there might be some thread-related bugs here or  
> there).
>
> I've been working through Paul Dietz's ANSI CL test suite, finding and
> fixing bugs as I go.  That test suite has been a very useful stress
> test, I must say.
>
> One important thing that remains to be done is to fill out some FFI
> details, primarily involving returning structures by value.  The IA-32
> ABI is not *that* complicated, so this might not be a terribly big
> job.  (Since Cocoa and Carbon return structures all day long, this
> means that the Cocoa IDE doesn't work yet.)  Also, Objective-C
> exception handling needs to be addressed.
>
> When the lisp passes the test suite, and the FFI details are filled
> in, it will be time to merge the ia32 branch with the trunk and
> unleash it on an unsuspecting world.
>
> If you're really adventurous, you can check out a copy of the current
> work-in-progress.  It only runs on Mac OS X.  I've only ever run it on
> Leopard.
>
> If you do this, *please* *please* *please* understand that this thing
> is really buggy, and we know that it's really buggy.  Please don't
> take the (non-) quality of the 32-bit Intel port as being
> representative of the other (x8664/ppc32/ppc64) ports, which are
> stable and reliable.
>
> If you've got Leopard with the developer tools installed, you can
> check out a working copy with the following command:
>
> $ svn co http://svn.clozure.com/publicsvn/openmcl/branches/ia32
>
> After that finishes, you should be able to build the lisp kernel, run
> the lisp, and recompile the sources:
>
> $ cd ia32/lisp-kernel/darwinx8632
> $ make
> [...]
> $ cd ../..
> $ ./dx86cl
> Welcome to Clozure Common Lisp Version 1.1-r8833:9797MS (DarwinX8632)!
> ? (rebuild-ccl :full t)
> [...]
> ;Wrote bootstrapping image: #P"/Users/rme/xxx/ia32/x86-boot32.image"
> ;Wrote heap image: #P"/Users/rme/xxx/ia32/dx86cl.image"
> ? (quit)
> $ ./dx86cl
> Welcome to Clozure Common Lisp Version 1.1-r8833:9797MS (DarwinX8632)!
> ?
>
> N.B.: the lisp kernel Makefile enables a debugging feature that makes
> the GC always use a slower, but more memory-efficient marker (we're
> doing this for stress-testing).  Also by default, flags are set in
> ccl::*gc-event-status-bits* that cause the GC to do heap integrity
> checking every time it runs.  The combination of these two things
> slows down GC by a huge amount.
>
> You might wish to run the lisp under gdb.  You'd say something like:
> $ gdb dx86cl
> (gdb) source lisp-kernel/darwinx8632/.gdbinit
> Breakpoint 1 at 0xe258: file ../lisp-debug.c, line 1003.
> (gdb) run
> Starting program: /Users/rme/xxx/ia32/dx86cl
> Reading symbols for shared libraries +. done
> Welcome to Clozure Common Lisp Version 1.1-r9799MS (DarwinX8632)!
> ?
>
> If you are crazy enough to try it out, I'd certainly like to hear
> about bugs you encounter, especially if you can provide a brief test
> case that exhibits the bug.  Please feel free to enter bugs in the
> Trac site at <http://trac.clozure.com/openmcl/>.
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel