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: Native Code Again Date: Fri, 28 Jan 2011 09:33:33 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1296225223 12305 80.91.229.12 (28 Jan 2011 14:33:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 28 Jan 2011 14:33:43 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 28 15:33:39 2011 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.69) (envelope-from ) id 1PipON-0004uA-9Z for guile-devel@m.gmane.org; Fri, 28 Jan 2011 15:33:39 +0100 Original-Received: from localhost ([127.0.0.1]:53605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PipOM-0002TK-J4 for guile-devel@m.gmane.org; Fri, 28 Jan 2011 09:33:38 -0500 Original-Received: from [140.186.70.92] (port=51590 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PipOK-0002SD-5Y for guile-devel@gnu.org; Fri, 28 Jan 2011 09:33:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PipOI-0008R4-Fr for guile-devel@gnu.org; Fri, 28 Jan 2011 09:33:36 -0500 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:55993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PipOI-0008Qq-DL for guile-devel@gnu.org; Fri, 28 Jan 2011 09:33:34 -0500 Original-Received: by yxl31 with SMTP id 31so1332579yxl.0 for ; Fri, 28 Jan 2011 06:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JrCsxwa9OoHUzmYz+LLHXBLU6uyhGBcB6SSy92tNceo=; b=PUsHG/pjZElxYRBjTZ8pHuSQBbcj07bY2r0s9xcbm3ZyANY/0gA1PVSaZ+2fj76KvI ooPYog5pDnFqyOFK9vHfO+G80wGVTvy4/5mxi2OAv1uVjYYIsVuk5jTblQBeKVOPfEMr i4YX8gmVfSm+HxMg8336KsYCqg890vVODDVRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TGv6W7WdfGtxXdjK6d5Y0AfLLquyRX52r2LvduumhEjv2Yj0GCftDLXiGiLxwseNgm 9T2PKCuH+H7cNNnyu//ZzZy61LMaUC6D1XBGp01kcMUTvhDICuGqd05R33voqNa3Is3u sJJrca5KhKrtiVG55VnrFqRARMbNU8f38iI/Y= Original-Received: by 10.150.229.11 with SMTP id b11mr2107400ybh.303.1296225213772; Fri, 28 Jan 2011 06:33:33 -0800 (PST) Original-Received: by 10.147.32.7 with HTTP; Fri, 28 Jan 2011 06:33:33 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: P75xaFqmoJNh1Gtu_-OsiCzSFa0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.213.169 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:11382 Archived-At: Him >> Therefore, I think the path to a native-code VM is to leave the VM as >> it is (except maybe reserve an opcode for native-code calls). Then I >> write first a C parser for Guile and then a converter program that >> would take Guile's current VM and output a JIT VM like I've described. > > Hah, it seems we concluded on the same thing after all... Yeah, it seems like that's the way to go. >> Specifically, you could construct the VM using the JITcode generator, >> either on Guile startup or whenever the user decided to enable native >> code generation. > > This is a very interesting possibility. =A0It scares me, in its > complexity, but it does seem to handle all of the objections that I had. The complexity actually scares me too. I only mentioned it because it seemed like the cleanest way to make tail calls work. After reading your email, though, maybe it's not worth it. > And also... why not rely on gcc's tail-call optimization, in the case > where it works? =A0You can check for it at configure-time. =A0I just ran > some small tests for tail-calls between functions in separate > compilation units and it shows that indeed, gcc does the right thing. I don't think you want to rely on that, because then programs might break at -O0 that would work fine at higher optimization levels. However, if GCC added a special intrinsic function that would always do a tail call, then that could work. And they might very well add it if we asked them to. > I guess that given this circumstance, things are a lot easier. =A0The JIT > library still needs to know how to tail-call a C function, but that is > more tractable. =A0If you don't have tail-calls, perhaps the JIT compiler > uses trampolines as you and Ludovic proposed; and that becomes a case > that only gets exercised with -O0, and possibly not even then if we add > -foptimize-sibling-calls when available. Well, the JIT library can already tail-call C code. That's the reason I had thought of using the JIT library to generate the VM. The main advantage of that is that tail calls would work everywhere the JIT works, so there wouldn't be any new restrictions on what platforms could use JIT. (Also, it frees me from having to do more work.) But even with that advantage, it could make startup really slow, and it's hugely complex, as you say. I suppose ultimately the best thing would be to make C code do tail calls. As far as I can tell, all major C compilers (gcc, icc, msvc, llvm) support inline assembly, so it can be done. It might be easiest, though, to do trampolines first, and then implement real tail calls platform-by-platform. (That may have been what you were saying, too.) Noah