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: Sun, 28 Nov 2010 15:58:18 -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 1290977916 1042 80.91.229.12 (28 Nov 2010 20:58:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 28 Nov 2010 20:58:36 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Nov 28 21:58:32 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 1PMoKL-0007y2-ET for guile-devel@m.gmane.org; Sun, 28 Nov 2010 21:58:30 +0100 Original-Received: from localhost ([127.0.0.1]:55280 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMoKL-0000GV-1B for guile-devel@m.gmane.org; Sun, 28 Nov 2010 15:58:29 -0500 Original-Received: from [140.186.70.92] (port=48765 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMoKG-0000FZ-Un for guile-devel@gnu.org; Sun, 28 Nov 2010 15:58:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PMoKF-0004fR-Iy for guile-devel@gnu.org; Sun, 28 Nov 2010 15:58:24 -0500 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:59210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PMoKF-0004fF-9y for guile-devel@gnu.org; Sun, 28 Nov 2010 15:58:23 -0500 Original-Received: by wwj40 with SMTP id 40so1983451wwj.30 for ; Sun, 28 Nov 2010 12:58:22 -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=PWCgCloFUd9MGYL/7cy+5QdmfGE8HVr3JXHY4gn5W5s=; b=EEwxHHlv2SrBVnHZpgg3nMOl/iHThJL9TZCm06uWHSEEy3apuXxB1Ug3uSid09HNAQ zPgU0iqviJUhlxyQ+xo5UPjpQwxm4dTYkM0j/Ghdi9pTP/CFf7kgXeoi4oHgP0pGOMF5 TL6Swg4v3Z+aceIn+EPUJckl2erOUkS6/EhRk= 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=ivsG6G8ESBVH68ShuOh3MWZ7RF92sQqwH2TTbbi4CWsEYG+xaRw7PeB3C8g3HhqTYx bnKExAkXVLPPXTQmYQaWllbxkI7eUXBt0Ob+56tLh/3MppLOp21aPNLxa8kL5DVY3Lht X4I0Ii3Z35L4F9XTehc+ZIqT29GV3kYNXHisw= Original-Received: by 10.216.231.146 with SMTP id l18mr4209390weq.52.1290977898361; Sun, 28 Nov 2010 12:58:18 -0800 (PST) Original-Received: by 10.216.237.34 with HTTP; Sun, 28 Nov 2010 12:58:18 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: CUkD_ZXYQWeeByfmxSHgnI6mM4k 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:11213 Archived-At: Hi, > I am concerned about complexity. I agree that complexity is a problem. I just sent an email about Jitgen, which is something I cooked up to reduce code duplication. However, I can't tell if it's going to end up reducing code complexity or increasing it. What do you think? > So what I would really like to see would be: > > * Ideally, a 4-word objcode representation that includes native > code. > * A well-defined convention for that native code. That's to say that > the native code could come from JIT compilation, or from AOT > compilation. Let me answer these together, because I think they affect each other. I've been poking around in the code, and noticed that procs.c has a reference to "applicable structs". As I understand it, these are structures that can also act as procedures. Procedures with setters are implemented this way. Is it possible to use these as containers for JITed code, and leave the objcode format alone? (And on a related note, is there any documentation for them?) I've been thinking about this because even if I could put JIT code in the objcode struct now, that wouldn't make much sense for AOT compiled code that wouldn't necessarily have or want objcode. It might be better to pick an interface to compiled code now that would work with AOT compiled code in the future, as you say. > * A uniform way to invoke native code from the VM, and VM code from > native code -- *preserving tail calls*. This seems to require either > trampolines within the VM or platform-specific tail-call assembly. This one could be hard. I can make JITed code call the VM as a tail call, because libjit will generate tail calls if you ask it to, but I don't see how to get from C code to JIT code without pushing onto the stack without either some assembly code or a trampoline. I think a trampoline would be easier, but I will ask on the libjit mailing list how people have solved this before. > * A uniform interface to create JIT code as needed, in the call > instructions. i.e. > if (SCM_UNLIKELY (SCM_NEEDS_JIT (proc))) > scm_jit_x (proc); > or something. That seems easy enough. Noah On Sat, Nov 20, 2010 at 8:37 AM, Andy Wingo wrote: > Hi, > > On Fri 22 Oct 2010 06:29, Noah Lavine writes: > >> After not emailing for a while, I have some good news: a JIT engine is w= orking! > > Great news! > > I have been behind on things a bit, so apologies for taking a month to > get back to you, and then only partially. In any case Ludovic probably > knows more both about assembly and JIT work, so I'm happy to not be a > "gatekeeper" of sorts here... > > That said, I am concerned about complexity. The current VM, though > obviously slow, does have the advantage of being relatively > simple. Adding a JIT complicates things. Well, adding another form of > compilation complicates things, JIT or AOT or whatever -- so my primary > concern is that, as we add native compilation, we need to keep things > mentally tractable. > > I have worked with many people who seem to be able to keep an inhuman > number of names and relationships in their head at one time. I fear I am > not such a person, so we will have to keep things extra-simple :) > > So what I would really like to see would be: > > =A0* Ideally, a 4-word objcode representation that includes native > =A0 =A0code. > > =A0* A well-defined convention for that native code. That's to say that > =A0 =A0the native code could come from JIT compilation, or from AOT > =A0 =A0compilation. > > =A0* A uniform way to invoke native code from the VM, and VM code from > =A0 =A0native code -- *preserving tail calls*. This seems to require eith= er > =A0 =A0trampolines within the VM or platform-specific tail-call assembly. > > =A0* A uniform interface to create JIT code as needed, in the call > =A0 =A0instructions. i.e. > =A0 =A0 =A0 =A0if (SCM_UNLIKELY (SCM_NEEDS_JIT (proc))) > =A0 =A0 =A0 =A0 =A0scm_jit_x (proc); > =A0 =A0or something. > > We should be able to merge all of that into Guile before any JIT code > goes in, and maybe even before 2.0 if the patches were small enough and > came fast enough ;-) Then we could take our time experimenting on how > best to do native compilation. > > So, to reiterate: *simple*, with a good *tail call* story. If we can > find a solution that has those characteristics, fantastic :) > > Andy > -- > http://wingolog.org/ >