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: Native Code Again Date: Sat, 8 Jan 2011 12:27:25 -0500 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1294507659 7694 80.91.229.12 (8 Jan 2011 17:27:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 8 Jan 2011 17:27:39 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jan 08 18:27:35 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 1PbcZi-0008Kd-GY for guile-devel@m.gmane.org; Sat, 08 Jan 2011 18:27:34 +0100 Original-Received: from localhost ([127.0.0.1]:52598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbcZh-0006tc-KF for guile-devel@m.gmane.org; Sat, 08 Jan 2011 12:27:33 -0500 Original-Received: from [140.186.70.92] (port=59613 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbcZc-0006tA-MZ for guile-devel@gnu.org; Sat, 08 Jan 2011 12:27:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PbcZb-0005SY-IM for guile-devel@gnu.org; Sat, 08 Jan 2011 12:27:28 -0500 Original-Received: from mail-wy0-f169.google.com ([74.125.82.169]:65428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PbcZb-0005S0-Dy for guile-devel@gnu.org; Sat, 08 Jan 2011 12:27:27 -0500 Original-Received: by wyj26 with SMTP id 26so19141739wyj.0 for ; Sat, 08 Jan 2011 09:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=42KD9cUQPgbASn9TJCs97Fi+fd91zXykj2+DkKcKc2E=; b=SDvya8Atg3FK3R5czIWly+GhW3TsEeZ4HzOutgmhO4vopEwFCdu714Ry1GLSHKIZrZ sQIWIZUV1hhW3ttqYVS7SDrQbs1Tt0IOaBzz5V/og5ak4i2WigP9nC7DKUk14MAqjeui 6TgfjIc3j9jLvfi8Yt3ffoNk3P73T65xBcHUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=N+EzYb2fGescLb80n74h4pBU7zA0YoLtOiU+P6fXWukglYvuNhFedZtCRGg+1w7jUa qnUDvAGfvasFoISXo0EAw/PqYVgEWCz7sIAIHGiuhhtnWHoJfrWX/vZa9t7Szv8vny0B ACOIk1x1CelkiE5DJtI993UG+bLSKWzsGVR2c= Original-Received: by 10.216.16.21 with SMTP id g21mr11177001weg.6.1294507645312; Sat, 08 Jan 2011 09:27:25 -0800 (PST) Original-Received: by 10.216.156.65 with HTTP; Sat, 8 Jan 2011 09:27:25 -0800 (PST) X-Google-Sender-Auth: UfTfncrkQnolRQZqUY1MH13fGZg X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:11303 Archived-At: Hello all, Sorry for all of the discussion about native code generation. I have another idea for how we could implement a good interface to JITed code. I've actually been thinking it for a while and initially dismissed it as too crazy, but now I'd like to see what you all think. The issue this solves that there is really no portable way for C code to do tail-calls. The ideal method of calling natively-generated code would be for the VM to tail call the JITed code, which would then tail call the VM when it was done. The only two ways of doing this are asking GCC to add a tail call intrinsic (unportable) or building a library of tail-call ASM for different platforms (more generally useful, but also basically unportable). However, there is a third possibility: don't have the VM be C code. Specifically, you could construct the VM using the JITcode generator, either on Guile startup or whenever the user decided to enable native code generation. The benefit of this is that the VM could communicate with native code using any method our JIT library supports, rather than any method you can do in portable C. Also, it introduces no new dependencies than what you need anyway for native code generation, since you would only need to do this in cases where you would be generating native code, and in that case you would have to have JIT capability anyway. The downside is that it's a big new batch of code to add to Guile. Just so you know, I have a thought on how to implement this. I posed here a while back about generating the VM from s-expressions, but I now have a different idea. I think that Guile should have a C code parser, if for no other reason than that we could parser C header declarations and make foreign function interfaces automatically. Given that, it wouldn't be too much more work to compile C to libjit. 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. One downside of this is that libjit probably doesn't have as good optimization abilities as GCC, so the VM produced might be slower. Another issue is that this is quite a bit of complexity, but actually most of the complexity would happen at the time we compile Guile, not Guile runtime. By the time Guile is running, the only remaining task should be to run libjit once and go. So, what do you all think? Noah