From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: CPS Update Date: Fri, 8 Mar 2013 17:57:44 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec52161798a3a7e04d771c18a X-Trace: ger.gmane.org 1362783500 26966 80.91.229.3 (8 Mar 2013 22:58:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 22:58:20 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Mar 08 23:58:44 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 1UE6FQ-0000Kf-1Y for guile-devel@m.gmane.org; Fri, 08 Mar 2013 23:58:44 +0100 Original-Received: from localhost ([::1]:49237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE6F4-0002YF-6T for guile-devel@m.gmane.org; Fri, 08 Mar 2013 17:58:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE6Ev-0002Xw-4Z for guile-devel@gnu.org; Fri, 08 Mar 2013 17:58:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UE6Ep-0005rE-8F for guile-devel@gnu.org; Fri, 08 Mar 2013 17:58:13 -0500 Original-Received: from mail-pb0-f54.google.com ([209.85.160.54]:52772) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE6Eo-0005r7-Sv for guile-devel@gnu.org; Fri, 08 Mar 2013 17:58:07 -0500 Original-Received: by mail-pb0-f54.google.com with SMTP id rr4so1688316pbb.13 for ; Fri, 08 Mar 2013 14:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=o7mRdcXwU8hWn28Wjs9TooWVV/GR+1zYVfOpWC/cMA0=; b=fKk0nxz+YcDqURplucqmCfKwCjbZCNhTLydVhLg+1W5MYfR9GfheXo2bh6S0H6XZLE Fm20bftKpgzDrwVnCKdTaRGH60JhtrAmjNxe2A/RJNTuglcwt2gSuw5Rb33HunvYBgBo S8P8ygqjGJDU8nFk1JTJ8TYkJmQIELFocWnAsNV8oUibumsJzCFUpcCq9Y04jIj6uB6P UDmNi8d+z16Hwg7QFaDPYzYUdn2U/IZxg/lDhH+Q897uAVI1sjQalk9HDv6fy5XjSE3G dwOA9CXDBlz421xoRlOGJstiOHibrrQgCAJ2aZhesI25h9lSRL0WPbtrMNZzXV+CgYTg Te+A== X-Received: by 10.68.39.195 with SMTP id r3mr6262573pbk.53.1362783485133; Fri, 08 Mar 2013 14:58:05 -0800 (PST) Original-Received: by 10.68.157.42 with HTTP; Fri, 8 Mar 2013 14:57:44 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: -25KFeSz_7DM7_XLsDFEZ00ISH8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.160.54 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:15887 Archived-At: --bcaec52161798a3a7e04d771c18a Content-Type: text/plain; charset=ISO-8859-1 Hello, Another quick update on CPS. I just pushed patches that implement closure conversion and use it to compile closures correctly. I think this is a big step forward for the CPS compiler. Since the last email, I've also implemented local mutable variables, and sequences (as part of that). Somewhat shockingly, I think that's almost every language feature. The other things (dynamic environment, prompts) can actually be done by making closures and calling the functions that implement them - it's just faster to use the RTL instructions. However, I think the primitive procedure generation is robust enough to handle those without too much trouble. The bigger task now is a combination of finding and eliminating bugs and slowly removing the ugly hacks I put in there. I don't think there are too many, but the way the closure conversion handles letrecs and the big case statement in the primitive instruction generator are notable examples. There are also some arbitrary limitations in the code - things like only allowing one argument to a procedure, or one procedure in a letrec. I put those in because I knew I could remove them without fundamentally changing things, and I wanted to sketch out the whole compiler first to get the organization right. Now I need to go through and fix all of that. But overall, I think the CPS compiler is going well. Best, Noah On Fri, Feb 15, 2013 at 7:53 PM, Noah Lavine wrote: > Hello, > > The wip-rtl-cps branch has been rebased again (on top of wip-rtl). It now > includes support for toplevel references and sets, thanks mostly to Andy's > work on supporting them in RTL. (Although you shouldn't kick that part of > it too hard just yet; I think I know where it will break.) Other highlights > include using the top-level variable support to evaluate "(+ 3 4)" > correctly. > > Overall, I think it's coming along well. The parts of Tree-IL that are > left to implement are local mutable variables (should be easy after > toplevel ones), module references and sets (very similar to top-level > ones), closures, and the dynamic environment stuff. Local mutable variables > are my next project, and then I think closures. > > One question I've had is, can we assume that the variables in the (guile) > module are immutable? I think the current compiler does this. Otherwise > there's no correct way to inline primitive procedures like + unless we have > a way to invalidate our compiled code and recompile it (which I would like > to have anyway, but that's a different story). > > Best, > Noah > > --bcaec52161798a3a7e04d771c18a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Another quick= update on CPS. I just pushed patches that implement closure conversion and= use it to compile closures correctly. I think this is a big step forward f= or the CPS compiler. Since the last email, I've also implemented local = mutable variables, and sequences (as part of that).

Somewhat shockingly, I think that's almost every language fea= ture. The other things (dynamic environment, prompts) can actually be done = by making closures and calling the functions that implement them - it's= just faster to use the RTL instructions. However, I think the primitive pr= ocedure generation is robust enough to handle those without too much troubl= e.

The bigger task now is a combination of finding and eliminating b= ugs and slowly removing the ugly hacks I put in there. I don't think th= ere are too many, but the way the closure conversion handles letrecs and th= e big case statement in the=A0 primitive instruction generator are notable = examples. There are also some arbitrary limitations in the code - things li= ke only allowing one argument to a procedure, or one procedure in a letrec.= I put those in because I knew I could remove them without fundamentally ch= anging things, and I wanted to sketch out the whole compiler first to get t= he organization right. Now I need to go through and fix all of that.

But overall, I think the CPS compiler is going well.

Best,
Noah



On Fri, Feb 15, 2013 at 7:53 PM, Noah Lavine <noah.= b.lavine@gmail.com> wrote:
Hello,

T= he wip-rtl-cps branch has been rebased again (on top of wip-rtl). It now in= cludes support for toplevel references and sets, thanks mostly to Andy'= s work on supporting them in RTL. (Although you shouldn't kick that par= t of it too hard just yet; I think I know where it will break.) Other highl= ights include using the top-level variable support to evaluate "(+ 3 4= )" correctly.

Overall, I think it's coming along well.=A0The part= s of Tree-IL that are left to implement are local mutable variables (should= be easy after toplevel ones), module references and sets (very similar to = top-level ones), closures, and the dynamic environment stuff. Local mutable= variables are my next project, and then I think closures.=A0

One question I've had is, can we assume that the va= riables in the (guile) module are immutable? I think the current compiler d= oes this. Otherwise there's no correct way to inline primitive procedur= es like + unless we have a way to invalidate our compiled code and recompil= e it (which I would like to have anyway, but that's a different story).=

Best,
Noah


--bcaec52161798a3a7e04d771c18a--