From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: full moon, vm status update Date: Wed, 15 Oct 2008 23:48:00 +0200 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1224107336 10183 80.91.229.12 (15 Oct 2008 21:48:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Oct 2008 21:48:56 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Oct 15 23:49:56 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KqEFS-0006GI-O9 for guile-devel@m.gmane.org; Wed, 15 Oct 2008 23:49:43 +0200 Original-Received: from localhost ([127.0.0.1]:38923 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqEEO-0002FH-6N for guile-devel@m.gmane.org; Wed, 15 Oct 2008 17:48:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KqEEK-0002Ef-H9 for guile-devel@gnu.org; Wed, 15 Oct 2008 17:48:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KqEEJ-0002Dn-Bm for guile-devel@gnu.org; Wed, 15 Oct 2008 17:48:31 -0400 Original-Received: from [199.232.76.173] (port=54058 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KqEEI-0002De-Ux for guile-devel@gnu.org; Wed, 15 Oct 2008 17:48:31 -0400 Original-Received: from a-sasl-fastnet.sasl.smtp.pobox.com ([207.106.133.19]:64833 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KqEEI-0005C4-Lt for guile-devel@gnu.org; Wed, 15 Oct 2008 17:48:30 -0400 Original-Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 45B266FC1D for ; Wed, 15 Oct 2008 17:48:28 -0400 (EDT) Original-Received: from unquote (117.Red-79-156-146.staticIP.rima-tde.net [79.156.146.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 5A3526FC1C for ; Wed, 15 Oct 2008 17:48:24 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Pobox-Relay-ID: 003FF002-9B03-11DD-97CE-1E1F86D30F62-02397024!a-sasl-fastnet.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7780 Archived-At: 'Sup, I was going to divide this update into the good, the bad, and the ugly, but the bad is the ugly, and the good contains within it the bad as well. The good: * I've hacked the disassembler to weave together the bits of information that it has into a more coherent text. So for example where in the past you would have a separate section after the program text listing the instruction <-> source associations, now the instruction disassembly is annotated with the source information directly. This required me to become format's daddy. http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/system/vm/disasm.scm;h=5ec1c004b42092a621792c1bc93e1c1b566a11fc;hb=vm#l171 I've appended a bit of disassembly to this mail. * Fixed another bug in quasiquote compilation. I don't expect any more, but then again, I didn't expect any more. * The VM stack is now marked precisely. * There is a now a debugging mode, currently turned on, in which we try ensure that the top of the stack is non-NULL and that all elements past the top are set to NULL. There are a number of checks in various places that this is the case. The idea is to avoid lost references when GC runs, and the heap structure's idea of the VM registers is out of sync with what the VM regs actually are; or there is some sloppy programming somewhere. When turned off, this code incurs no overhead. This mode helped to catch a number of stack GC bugs. * All of Guile's test suites pass now, with (ice-9 ...) compiled, including boot-9. The bad: (It's like a C switch statement, it all falls through to the ugly.) The ugly: * Actually the bit about all of the test suites passing was a lie in another respect: the elisp test fails, with a C stack overflow, indicating too much recursion into the interpreter. I suspect this is because some part of the elisp code depends on tail calls within interpreted code, but you don't get tail call semantics when calling between VM code and interpreted code, just as you do not with calling between e.g. interpreted and C code. I was hoping that the stack calibration patches would land sooner or later in master so that I could merge and pick up this code, because the truth is that it's all too easy to hit the limit, for whatever reason. I have not yet tested the calibration patches. * I had to disable compilation of popen.scm in order to get the tests to pass, as it was causing really strange, nondeterministic things to happen. I don't know why. My current speculation is that when you compile --with-threads, as I do, that the socketpair between the signal receiving thread and the main thread is not closed after the fork, therefore signals in the child might reach the parent or vice versa, causing random code to run which itself might cause VM problems. Julian: if you have read this far and have the cycles, can you say something about the state of the signal socketpair after a fork? * Still there are a couple other modules not being compiles. The future: * Compile more modules -- srfi, third-level modules -- (ice-9 foo bar) * Fix GOOPS to be VM-compatible * Compile *and* interpret the test suites * Update docs (maybe merging with guile.texi) and, once things are correct... * Profile, profile, profile My goal is: correct execution of all existing code that: * does not do runtime side-effects in macros * does not call (the-environment) * does not unquote in values into macros Well that's a long enough update! Questions, comments, and help are most welcome. Happy hacking, Andy ps. Here's the disassembly I promised: scheme@(guile-user)> ,x with-output-to-file Disassembly of #: nargs = 2 nrest = 0 nlocs = 2 nexts = 0 Bytecode: 0 (late-variable-ref 0) ;; `open-output-file' 2 (local-ref 0) ;; `file' (arg) 4 (call 1) at r4rs.scm:145:16 6 (local-set 2) ;; `nport' 8 (late-variable-ref 1) ;; `with-output-to-port' 10 (local-ref 2) ;; `nport' 12 (local-ref 1) ;; `thunk' (arg) 14 (call 2) at r4rs.scm:146:14 16 (local-set 3) ;; `ans' 18 (late-variable-ref 2) ;; `close-port' 20 (local-ref 2) ;; `nport' 22 (call 1) at r4rs.scm:147:4 24 (drop) 25 (local-ref 3) ;; `ans' 27 (return) Properties: #f (documentation . "THUNK must be a procedure of no arguments, and FILE must be a string naming a file. The effect is unspecified if the file already exists. The file is opened for output, an output port connected to it is made the default value returned by `current-output-port', and the THUNK is called with no arguments. When the THUNK returns, the port is closed and the previous default is restored. Returns the value yielded by THUNK. If an escape procedure is used to escape from the continuation of these procedures, their behavior is implementation dependent.") (If you read this and worry about runtime costs, don't -- the annotations and properties are not loaded until they are asked for) -- http://wingolog.org/