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: Guile 2.2 TODO Date: Sun, 01 Sep 2013 13:03:46 +0200 Message-ID: <87vc2kztv1.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1378033444 4800 80.91.229.3 (1 Sep 2013 11:04:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Sep 2013 11:04:04 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Sep 01 13:04:08 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VG5Rv-0000gq-M4 for guile-devel@m.gmane.org; Sun, 01 Sep 2013 13:04:07 +0200 Original-Received: from localhost ([::1]:33397 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VG5Ru-0006ZT-RK for guile-devel@m.gmane.org; Sun, 01 Sep 2013 07:04:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VG5Rm-0006YJ-Iv for guile-devel@gnu.org; Sun, 01 Sep 2013 07:04:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VG5Rh-0000zI-Gs for guile-devel@gnu.org; Sun, 01 Sep 2013 07:03:58 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:48463 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VG5Rh-0000zB-CC for guile-devel@gnu.org; Sun, 01 Sep 2013 07:03:53 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4208BCB2D for ; Sun, 1 Sep 2013 07:03:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:date:message-id:mime-version:content-type; s=sasl; bh=V MnfxbsUBUZCGqGJJAOfyQDz/Ws=; b=yGNTflhaO4PYX7HoAJMbyrnhz/dS5y/ZT mKjsMtgGTB5Ae/uHU4XZa1Qn7e6CyCyp608viJ1W0kVw471vXFcVnfrOAFtLuhdB 4bThAWmo7ftH+MqYiJVq1IUkq+wEl3eLhvi7+TLyoVTpkv3fTvWr8UJ5IPvYr7xY mma4VWuPUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :date:message-id:mime-version:content-type; q=dns; s=sasl; b=u3k r4bwUAZi04+eQ5X/Nob6FQncZIen52aTCbKh1C1LrzbThsjS4wlZSbtEraJ+uy/p JInriDW3hp14pb2RBulGtVVdSnDS4qpXCaVDLFN3MajwurG9l0WT79MnZpt9KfYZ fQD5jc87G0as2PRtNYvdF4CksGCM1A1xLc9EaWq8= Original-Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2837ECB2C for ; Sun, 1 Sep 2013 07:03:52 -0400 (EDT) Original-Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 0B214CB2A for ; Sun, 1 Sep 2013 07:03:50 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Pobox-Relay-ID: 2F09F728-12F6-11E3-AB79-CE710E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 208.72.237.25 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16603 Archived-At: Hi! So, the RTL VM and the CPS compiler landed. I think the consensus is that Guile 2.2 is basically what's in master, all compiled to RTL. Anything else we manage to get in is great but that's the fundamental bit. To that end, we should start to think about what is necessary to finish the job, now that we're close. I'm going to try to leave off things that aren't necessary but would be nice to have, such as particular optimization passes. Those can always be added later. * Test cases I'm going to go ahead and mention this one first -- though it's more part of "the way to get there" and not of "where we're going", writing tests will be really useful to determine which parts of the compiler are working and which are not. This is the easiest, most productive way for someone interested in this work to contribute. Add a test to test-suite/tests/rtl-compilation.test and commit the patch! If it fails, even better. * Source information. The plan here would be to use DWARF. We don't use DWARF yet, so there are a few parts of this. - Add a DWARF parser; see the wip-dwarf branch for that. - Emit debugging info entries (DIEs) for each function in a compilation unit, into the .debug_info section. Initially they would be minimal, just having the function's address and maybe its name. - Add machinery to (system vm debug) to get a DIE for a procedure, if it is present. - Add a macro-instruction to the assembler that records source location info. Have the assembler collect this info. - Have the assembler write out source location info into a .debug_line section, and link the DIE to that info. - Add an appropriate interface to (system vm debug) to parse out line number information. Perhaps model this interface on what is already in (system vm program). - Shim the existing (system vm program) interfaces to call the new (system vm debug) interfaces for RTL programs. * Local variable information. This is similar. Assuming source information is done, you have to add DW_TAG_variable entries for each variable to their function's DIE, and link those entries to location lists in the .debug_loc section. A location list specifies the bytecode ranges for which a variable is live. Then you have to parse it out as well; the existing interfaces in (system vm program) can be a guide. This involves some compiler hacking, because we don't explicitly compute liveness ranges. I expect we'd have to compute an order in which to emit labelled expressions (continuations), and use that order in the slot allocator, the bytecode emitter, and of course when emitting live/dead labels. Maybe not, though; maybe it would be sufficient to just associate live-set used in the slot allocator with each continuation. Dunno. Ideally this gets linked up to the disassembler too. * Replace bytecode trampolines with RTL trampolines. foreign.c, control.c, gsubr.c, and continuations.c all have inline bytecode trampolines to implement calls to "foreign" things. These need to be replaced with RTL trampolines. This can be done now, I think, and doesn't depend on anything else, given that the two VMs interoperate. * Prompt, abort, and call/cc. These bits have stub implementations in the VM and aren't yet implemented in the compiler. I think Mark Weaver is on this though, so hopefully this situation shouldn't last too long. * Compiling all of Guile to RTL. As I mentioned, guild compile -t rtl foo.scm will compile to RTL, and that interoperates fine with the old VM (modulo tail calls). We can try this by hand, file by file, checking that things work. Then we would switch the order of the compilers in (language tree-il spec) to make CPS preferred over GLIL. * Rip out GLIL, assembly, bytecode, objcode, the old VM, etc.. This will be a final glorious set of commits :) * Update documentation The manual will need updating. I'm OK with putting this off to the end. I think that's pretty much it. Obviously it would be nice to get a lot of other things into 2.2 but this is the necessary bit. I think we should shoot for a 2.1.0 release around 1 December; dunno. WDYT? If no one else is up to it, I'll get on source location info in a couple weeks. Andy -- http://wingolog.org/