From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-rtl return location Date: Thu, 02 Aug 2012 22:29:03 -0400 Message-ID: <501B376F.3060505@netris.org> References: <87mx2dv02q.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1343960968 26539 80.91.229.3 (3 Aug 2012 02:29:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2012 02:29:28 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Aug 03 04:29:27 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 1Sx7dk-0001sx-4d for guile-devel@m.gmane.org; Fri, 03 Aug 2012 04:29:24 +0200 Original-Received: from localhost ([::1]:41981 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx7dj-0002qY-8A for guile-devel@m.gmane.org; Thu, 02 Aug 2012 22:29:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx7dg-0002qG-Cg for guile-devel@gnu.org; Thu, 02 Aug 2012 22:29:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sx7df-0004uj-CA for guile-devel@gnu.org; Thu, 02 Aug 2012 22:29:20 -0400 Original-Received: from world.peace.net ([96.39.62.75]:59948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx7df-0004ue-7T for guile-devel@gnu.org; Thu, 02 Aug 2012 22:29:19 -0400 Original-Received: from 209-6-92-20.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.92.20] helo=[10.0.1.200]) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Sx7dX-00076t-GW; Thu, 02 Aug 2012 22:29:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 In-Reply-To: <87mx2dv02q.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 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:14767 Archived-At: Hi Andy, thanks for the update! Exciting times for Guile :) On 08/02/2012 10:29 AM, Andy Wingo wrote: > 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). I wonder if it might be better to avoid this branch misprediction by always returning to the same address. Upon return, a special register would contain N-1, where N is the number of return values. The first few return values would also be stored in registers (hopefully at least two), and if necessary the remaining values would be stored elsewhere, perhaps on the stack or in a list or vector pointed to by another register. In the common case where a given call site expects a small constant number of return values, the compiler could emit a statically-predicted conditional branch to verify that N-1 is the expected value (usually zero), and then generate code that expects to find the return values in the appropriate registers. On some architectures, it might also make sense for the callee to set the processor's "zero?" condition code as if N-1 had been tested, to allow for a shorter check in the common single-value case. Of course, the calling convention can be chosen independently for each instruction set architecture / ABI. What do you think? Mark