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: wip-rtl return location Date: Thu, 2 Aug 2012 18:21:02 -0400 Message-ID: References: <87mx2dv02q.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1343946072 27196 80.91.229.3 (2 Aug 2012 22:21:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2012 22:21:12 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Aug 03 00:21:11 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sx3lU-0001Pv-J9 for guile-devel@m.gmane.org; Fri, 03 Aug 2012 00:21:08 +0200 Original-Received: from localhost ([::1]:39558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx3lT-0001dg-Se for guile-devel@m.gmane.org; Thu, 02 Aug 2012 18:21:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx3lQ-0001db-Rn for guile-devel@gnu.org; Thu, 02 Aug 2012 18:21:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sx3lP-0001u4-8t for guile-devel@gnu.org; Thu, 02 Aug 2012 18:21:04 -0400 Original-Received: from mail-ob0-f169.google.com ([209.85.214.169]:60937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx3lP-0001ty-3Z for guile-devel@gnu.org; Thu, 02 Aug 2012 18:21:03 -0400 Original-Received: by obhx4 with SMTP id x4so70522obh.0 for ; Thu, 02 Aug 2012 15:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JIbgqHwjah8fPkQjtnhpC+DnU/F3lqg5rO1BNn6AKH8=; b=GkI57D2671CbGmTiPh2tmPCNxzRomPKgBKW53F7ew3cWZv9sEJugeIKsNc1QbRZDHR RZHBOw8XUuCWnF3aLLn45H2OmrtS7LW7WPlKecBcdPIXBcSAFc2Ts9qK01iQ1j/6QKrA aIEhqC11F5yZHHF2eCtTDNY152zZFNogwkRPdT9j8y0YE482lyiR0S01CHU3RnO2+p99 veBEkCaQQPoNcJk5+l/xgeZoJ1uaXZaBnTyxh9PX84rHv5+rz5KpABGN6Y7+16aMkSB9 cRlZSTQNBoL0eiyJ8XxWfsy4unlXsf8+KVnNDAlKmAO5TQGRphqiJVkJsD8NRkQ29tfx Hpkw== Original-Received: by 10.182.226.104 with SMTP id rr8mr40812356obc.41.1343946062150; Thu, 02 Aug 2012 15:21:02 -0700 (PDT) Original-Received: by 10.76.152.3 with HTTP; Thu, 2 Aug 2012 15:21:02 -0700 (PDT) In-Reply-To: <87mx2dv02q.fsf@pobox.com> X-Google-Sender-Auth: vmxOoWph4XKZ12hcj02Hoajc8TM X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14766 Archived-At: That sounds interesting, but I have a question - why not make the MVRA return address immediately after the call, instead of immediately before it? In the common case when returning to the regular return address, that would eliminate the extra branch (although it's a very small branch anyway). I would guess the reason to put it before is for variable-length instructions, but you could handle that by reserving enough bytes for a jump instruction. So it would look like CALL: call f MVRA: jump mv-handler RA: ... rest of function ... I really don't know if this is better or not. I'm just curious why it isn't arranged like this. Thanks, Noah On Thu, Aug 2, 2012 at 10:29 AM, Andy Wingo wrote: > Hi, > > Some brief thoughts on the wip-rtl branch. Currently it has this > strange "return location" thing, where it specifies the register(s) to > which to return value(s), and the number of expected values and whether > it expects a rest list or not. Problem is, this return location is like > a little program that needs to be interpreted at runtime. Worse, it > seems to assume that return values will have to be passed in memory. > > Instead I'd rather just use Dybvig's suggestion: every call instruction > is preceded by an MV return address. For e.g. (values (f)), calling `f' > would be: > > ... > goto CALL > MVRA: > truncate-and-jump RA > CALL: > call f > RA: > return > > So the overhead of multiple values in the normal single-value case is > one jump per call. When we do native compilation, this cost will be > negligible. OTOH for MV returns, we return to a different address than > the one on the stack, which will cause a branch misprediction (google > "return stack buffers" for more info). Of course this is not relevant > to the interpreter, because all of these branches are indirect, but it > will be in the future, so it's a good idea to think about these things > now. With this design, the caller is responsible for handling MV > returns, not the callee. > > Anyway, MV return will cause a branch misprediction. Oh well. I think > we can live with it. Single-valued returns are the common case, and > they will be predicted correctly. > > So, another thing. The reason for the previous "return location" design > was because I wanted to have just two registers reserved by the > implementation: the instruction pointer and the frame pointer. Wanting > an IP is obvious. It's important to locate frame pointers so that > various pieces of code can walk the stack frames: for example the > delimited continuation code, the backtrace printer, the debugger, etc. > It's possible to just using a stack pointer and use dynamic tables to > find where the frame pointer is, like the x86-64 architecture does (or > -fomit-frame-pointer), but that requires more sophistication on the part > of the runtime, and I don't think we're really ready for that right now. > > As I said, I wanted just the IP and the FP. I didn't want an SP because > it causes so much performance noise in the current VM. But then I > realized that in the RTL VM, it doesn't need to be accessed frequently, > because more values are addressed against the FP, and we're not pushing > and popping temporaries. So we can actually keep it around, and it > might not need to be in a register. It retains its useful > characteristics of allowing variable-sized data to be (temporarily) > allocated on the stack, as in procedure calls or MV returns, and as a > stack delimiter for GC. > > In summary: > > - I will remove the "return location" stuff from wip-rtl; > > - All calls will be mv-calls > > - MV returns will return to 1 instruction before the RA > > - All calls will be preceded by a jump over the MVRA > > - Eventually we can remove the MVRA slot from stack frames, because it > is computable from the RA > > - The stack pointer is back in town! > > Andy > -- > http://wingolog.org/ >