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: A Working (but Minimal) JIT Date: Mon, 6 Dec 2010 17:53:25 -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 1291676121 10039 80.91.229.12 (6 Dec 2010 22:55:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Dec 2010 22:55:21 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Dec 06 23:55:16 2010 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 1PPjxh-0000ls-SH for guile-devel@m.gmane.org; Mon, 06 Dec 2010 23:55:14 +0100 Original-Received: from localhost ([127.0.0.1]:48493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPjxh-0004I8-7p for guile-devel@m.gmane.org; Mon, 06 Dec 2010 17:55:13 -0500 Original-Received: from [140.186.70.92] (port=56734 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPjw0-0008T4-SN for guile-devel@gnu.org; Mon, 06 Dec 2010 17:53:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPjvz-0006Va-4q for guile-devel@gnu.org; Mon, 06 Dec 2010 17:53:28 -0500 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:63441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPjvz-0006VQ-0X for guile-devel@gnu.org; Mon, 06 Dec 2010 17:53:27 -0500 Original-Received: by wwb17 with SMTP id 17so4729408wwb.30 for ; Mon, 06 Dec 2010 14:53: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 :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=TYlCRvSoxeGYCGj4Q7/NBa22czVsU/2VzP/IWuPcB24=; b=ZxjK3brtQc9WnDLxqWdhHVn181tcsPPbVBa/1vlI1GHguKLXSFLC7F9rooE0mdBB/M /zdgGWsLB74Y6Di5vABTPggQ0a0qE2Fxc7yqf9JoUINgahVcFZjTEg8u7FI/I0b3IK0P +AzQLdeZcgKg6jXwjxpYsVRXsMj/efmTo48gg= 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=ucsO5cKG/bxXg5/72egJhw4DsobmSeOeXaJHC/sv3095Fz9z8EQRKtK0QNdNbhsF1U VEr95B5gmXigv1boIgPNScV5ztmtfw6pMnyD8cJfmToqzICbgIPZB+UFxEYbxcu7dNDW hbp75WxycEI4wtgHnX/D86mEgcEPFOoagATtA= Original-Received: by 10.216.166.66 with SMTP id f44mr692069wel.37.1291676005754; Mon, 06 Dec 2010 14:53:25 -0800 (PST) Original-Received: by 10.216.237.34 with HTTP; Mon, 6 Dec 2010 14:53:25 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: Mmcrm9cEAPKSUCHWt1eXMBiOjrk 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:11235 Archived-At: Hi, > Regarding whether or not to jit, I'm OK with doing that in the `call' > instruction. Sounds good. I'll put it in there. (And also in 'mv-call' and 'tail-call'.) > But regarding how to call a natively-compiled function -- I think this > is really, really critical. =A0It's an important decision that will have > some far-reaching effects. =A0I would like for natively-compiled function= s > to get their objcode replaced with a short stub that tail-calls the > native code -- maybe the stub would consist of just one instruction, > `native-call' or something. =A0(Obviously this instruction doesn't exist > yet). =A0That instruction would do a tail call in such a way that the vm > engine is no longer on the stack. > > I am concerned about JIT libraries precisely because they tend to impose > a C calling convention on native code, without allowing for more > appropriate conventions that allow for tail calls and multiple values on > the stack. I see what you mean, but I don't know of a library that fixes that. The problem I'm having with the current code is that (I think) there is no portable way to jump from C code to another function (or block of machine code of any sort) without pushing a frame on the stack. A normal C function call makes the stack deeper (unless the compiler optimizes it, which is a GCC thing), and using a goto where the target isn't fixed at compile time is a GCC extension. And the only other way for a C program to do a jump is setjmp and longjmp, but I don't see a way to use those for this. I think that the best way is to use inline assembly to make the tail call. But in order to do that portably, we would need a macro that expanded to different code for GCC, MSVC, and any other compilers that Guile wanted to support, as well as different code for different architectures. My idea is to first do it with a trampoline, and then maybe replace the trampoline with a macro like that. How does all of this sound? > Anyway, these are my concerns. =A0Obviously you're the one hacking the > code, so do what you like :) I agree with your concerns. Thanks a lot for showing me how to do this. Noah