[Openmcl-devel] 32-bit x86 port update

[useada.u]

Greate！
And I am tring。。。


2008-06-20 



useada.u 



发件人： R. Matthew Emerson 
发送时间： 2008-06-20  13:39:36 
收件人： openmcl-devel at clozure.com 
抄送： 
主题： [Openmcl-devel] 32-bit x86 port update 
 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20080620/0877b3a8/attachment.htm>