<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE>@font-face {
font-family: 宋体;
}
@font-face {
font-family: Verdana;
}
@font-face {
font-family: @宋体;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; layout-grid: 15.6pt; }
P.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoNormal {
TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: personal-compose
}
DIV.Section1 {
page: Section1
}
UNKNOWN {
FONT-SIZE: 10pt
}
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>
</HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: verdana">
<DIV><FONT size="2" color="#000080" face="Verdana">Greate！</FONT></DIV>
<DIV><FONT color="#000080">And I am tring。。。</FONT></DIV>
<DIV><FONT size="2" color="#000080" face="Verdana"></FONT> </DIV>
<DIV><FONT size="2" color="#000080" face="Verdana"></FONT> </DIV>
<DIV><FONT size="2" color="#c0c0c0" face="Verdana">2008-06-20 </FONT></DIV><FONT size="2" color="#000080" face="Verdana">
<HR SIZE="2" align="left" style="WIDTH: 122px; HEIGHT: 2px">
</FONT>
<DIV><FONT size="2" color="#c0c0c0" face="Verdana"><SPAN>useada.u</SPAN>
</FONT></DIV><FONT size="2" color="#000080" face="Verdana">
<HR>
</FONT>
<DIV><FONT size="2" face="Verdana"><STRONG>发件人：</STRONG> R. Matthew Emerson
</FONT></DIV>
<DIV><FONT size="2" face="Verdana"><STRONG>发送时间：</STRONG> 2008-06-20 13:39:36
</FONT></DIV>
<DIV><FONT size="2" face="Verdana"><STRONG>收件人：</STRONG> openmcl-devel@clozure.com
</FONT></DIV>
<DIV><FONT size="2" face="Verdana"><STRONG>抄送：</STRONG> </FONT></DIV>
<DIV><FONT size="2" face="Verdana"><STRONG>主题：</STRONG> [Openmcl-devel] 32-bit x86
port update </FONT></DIV>
<DIV><FONT size="2" face="Verdana"></FONT> </DIV>
<DIV><FONT size="2" face="Verdana">
<DIV>Here is a status update on the 32-bit x86 port.</DIV>
<DIV> </DIV>
<DIV>There's been some good progress since the last status message I sent </DIV>
<DIV>out about six or seven weeks ago.</DIV>
<DIV> </DIV>
<DIV>The lisp (I think it's fair to call it a lisp now) can self-host. In </DIV>
<DIV>other words, it compiles itself now. I very rarely have any occasion </DIV>
<DIV>to cross-compile it any more.</DIV>
<DIV> </DIV>
<DIV>The GC works. I'm chasing a heap corruption bug or two, but I think </DIV>
<DIV>it's unlikely that the corruption is the GC's fault. (One of the bits </DIV>
<DIV>that can be set in ccl::*gc-event-status-bits* turns on heap integrity </DIV>
<DIV>checking in the GC. This causes the GC to check the heap before and </DIV>
<DIV>after it does its thing. So far, the heap corruption has always been </DIV>
<DIV>reported in the pre-gc heap integrity check.)</DIV>
<DIV> </DIV>
<DIV>You can now use SLIME (which implies that basic threading is working, </DIV>
<DIV>though I suspect there might be some thread-related bugs here or there).</DIV>
<DIV> </DIV>
<DIV>I've been working through Paul Dietz's ANSI CL test suite, finding and </DIV>
<DIV>fixing bugs as I go. That test suite has been a very useful stress </DIV>
<DIV>test, I must say.</DIV>
<DIV> </DIV>
<DIV>One important thing that remains to be done is to fill out some FFI </DIV>
<DIV>details, primarily involving returning structures by value. The IA-32 </DIV>
<DIV>ABI is not *that* complicated, so this might not be a terribly big </DIV>
<DIV>job. (Since Cocoa and Carbon return structures all day long, this </DIV>
<DIV>means that the Cocoa IDE doesn't work yet.) Also, Objective-C </DIV>
<DIV>exception handling needs to be addressed.</DIV>
<DIV> </DIV>
<DIV>When the lisp passes the test suite, and the FFI details are filled </DIV>
<DIV>in, it will be time to merge the ia32 branch with the trunk and </DIV>
<DIV>unleash it on an unsuspecting world.</DIV>
<DIV> </DIV>
<DIV>If you're really adventurous, you can check out a copy of the current </DIV>
<DIV>work-in-progress. It only runs on Mac OS X. I've only ever run it on </DIV>
<DIV>Leopard.</DIV>
<DIV> </DIV>
<DIV>If you do this, *please* *please* *please* understand that this thing </DIV>
<DIV>is really buggy, and we know that it's really buggy. Please don't </DIV>
<DIV>take the (non-) quality of the 32-bit Intel port as being </DIV>
<DIV>representative of the other (x8664/ppc32/ppc64) ports, which are </DIV>
<DIV>stable and reliable.</DIV>
<DIV> </DIV>
<DIV>If you've got Leopard with the developer tools installed, you can </DIV>
<DIV>check out a working copy with the following command:</DIV>
<DIV> </DIV>
<DIV>$ svn co <A href="http://svn.clozure.com/publicsvn/openmcl/branches/ia32">http://svn.clozure.com/publicsvn/openmcl/branches/ia32</A></DIV>
<DIV> </DIV>
<DIV>After that finishes, you should be able to build the lisp kernel, run </DIV>
<DIV>the lisp, and recompile the sources:</DIV>
<DIV> </DIV>
<DIV>$ cd ia32/lisp-kernel/darwinx8632</DIV>
<DIV>$ make</DIV>
<DIV>[...]</DIV>
<DIV>$ cd ../..</DIV>
<DIV>$ ./dx86cl</DIV>
<DIV>Welcome to Clozure Common Lisp Version 1.1-r8833:9797MS (DarwinX8632)!</DIV>
<DIV>? (rebuild-ccl :full t)</DIV>
<DIV>[...]</DIV>
<DIV>;Wrote bootstrapping image: #P"/Users/rme/xxx/ia32/x86-boot32.image"</DIV>
<DIV>;Wrote heap image: #P"/Users/rme/xxx/ia32/dx86cl.image"</DIV>
<DIV>? (quit)</DIV>
<DIV>$ ./dx86cl</DIV>
<DIV>Welcome to Clozure Common Lisp Version 1.1-r8833:9797MS (DarwinX8632)!</DIV>
<DIV>?</DIV>
<DIV> </DIV>
<DIV>N.B.: the lisp kernel Makefile enables a debugging feature that makes </DIV>
<DIV>the GC always use a slower, but more memory-efficient marker (we're </DIV>
<DIV>doing this for stress-testing). Also by default, flags are set in </DIV>
<DIV>ccl::*gc-event-status-bits* that cause the GC to do heap integrity </DIV>
<DIV>checking every time it runs. The combination of these two things </DIV>
<DIV>slows down GC by a huge amount.</DIV>
<DIV> </DIV>
<DIV>You might wish to run the lisp under gdb. You'd say something like:</DIV>
<DIV>$ gdb dx86cl</DIV>
<DIV>(gdb) source lisp-kernel/darwinx8632/.gdbinit</DIV>
<DIV>Breakpoint 1 at 0xe258: file ../lisp-debug.c, line 1003.</DIV>
<DIV>(gdb) run</DIV>
<DIV>Starting program: /Users/rme/xxx/ia32/dx86cl</DIV>
<DIV>Reading symbols for shared libraries +. done</DIV>
<DIV>Welcome to Clozure Common Lisp Version 1.1-r9799MS (DarwinX8632)!</DIV>
<DIV>?</DIV>
<DIV> </DIV>
<DIV>If you are crazy enough to try it out, I'd certainly like to hear </DIV>
<DIV>about bugs you encounter, especially if you can provide a brief test </DIV>
<DIV>case that exhibits the bug. Please feel free to enter bugs in the </DIV>
<DIV>Trac site at <<A href="http://trac.clozure.com/openmcl/">http://trac.clozure.com/openmcl/</A>
>.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>_______________________________________________</DIV>
<DIV>Openmcl-devel mailing list</DIV>
<DIV>Openmcl-devel@clozure.com</DIV>
<DIV><A href="http://clozure.com/mailman/listinfo/openmcl-devel">http://clozure.com/mailman/listinfo/openmcl-devel</A></DIV></FONT></DIV></BODY></HTML>