From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: Native Code Again Date: Fri, 28 Jan 2011 11:19:55 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1296231767 17911 80.91.229.12 (28 Jan 2011 16:22:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 28 Jan 2011 16:22:47 +0000 (UTC) Cc: Andy Wingo , guile-devel@gnu.org To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 28 17:22:42 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 1Pir5t-0000K1-ON for guile-devel@m.gmane.org; Fri, 28 Jan 2011 17:22:41 +0100 Original-Received: from localhost ([127.0.0.1]:39131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pir5t-0006m5-1w for guile-devel@m.gmane.org; Fri, 28 Jan 2011 11:22:41 -0500 Original-Received: from [140.186.70.92] (port=60501 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pir3L-0005Ip-9S for guile-devel@gnu.org; Fri, 28 Jan 2011 11:20:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pir3I-0006ud-MV for guile-devel@gnu.org; Fri, 28 Jan 2011 11:20:01 -0500 Original-Received: from mail-qy0-f169.google.com ([209.85.216.169]:58312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pir3I-0006uV-Jt for guile-devel@gnu.org; Fri, 28 Jan 2011 11:20:00 -0500 Original-Received: by qyk7 with SMTP id 7so972889qyk.0 for ; Fri, 28 Jan 2011 08:19:59 -0800 (PST) Original-Received: by 10.224.19.135 with SMTP id a7mr2904135qab.153.1296231599318; Fri, 28 Jan 2011 08:19:59 -0800 (PST) Original-Received: from squish.raeburn.org (c-24-128-190-224.hsd1.ma.comcast.net [24.128.190.224]) by mx.google.com with ESMTPS id y17sm12731541qci.33.2011.01.28.08.19.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 08:19:58 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.1082) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.216.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:11388 Archived-At: On Jan 28, 2011, at 09:33, Noah Lavine wrote: >=20 >> And also... why not rely on gcc's tail-call optimization, in the case >> where it works? You can check for it at configure-time. I just ran >> some small tests for tail-calls between functions in separate >> compilation units and it shows that indeed, gcc does the right thing. >=20 > 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. It's also dependent on code-specific and machine-specific parameters = that are coded into gcc; skimming some sources briefly (and keep in = mind, I'm a bit rusty at this), it looks like: * various cases of needing different amounts of stack space for = arguments * alpha: target must be known to use same $gp value; no indirect calls * arm: can't be 'long' call out of range of short branch insn; no = indirect calls * ia64: target must be known to use same GP * pa: must be 32-bit mode; target must be static function in same file = if not ELF; no "portable runtime"? * rs6000: no indirect calls; target must be static (I think?) if AIX * rx: no indirect calls * sparc: no indirect calls There are other constraints I've ignored, for example if return = registers differ (because return types are different) or some cases of = PIC code generation (unless you're thinking of writing out object code = to reload later?). The requirements for no indirect calls need to be = looked at platform by platform; I expect for the generated code that we = would be using indirect calls, wouldn't we, with target addresses loaded = from structures? > 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. >=20 > 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. They probably all do, but you'd have to know how to release the stack = frame, possibly restore saved registers, put the outgoing arguments into = the right locations, adjust for differing numbers of arguments, etc. > 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.) Starting with trampolines seems like a good idea to me. Ken=