From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-rtl return location Date: Fri, 03 Aug 2012 10:06:47 +0200 Message-ID: <873944v1pk.fsf@pobox.com> References: <87mx2dv02q.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1343981311 26804 80.91.229.3 (3 Aug 2012 08:08:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2012 08:08:31 +0000 (UTC) Cc: guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Aug 03 10:08:28 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 1SxCvs-0005yo-IS for guile-devel@m.gmane.org; Fri, 03 Aug 2012 10:08:28 +0200 Original-Received: from localhost ([::1]:36876 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxCvr-0004SM-Pq for guile-devel@m.gmane.org; Fri, 03 Aug 2012 04:08:27 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxCuN-0000sX-BI for guile-devel@gnu.org; Fri, 03 Aug 2012 04:07:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SxCuI-0007B0-RV for guile-devel@gnu.org; Fri, 03 Aug 2012 04:06:55 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:33313 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxCuI-0007Ai-MW for guile-devel@gnu.org; Fri, 03 Aug 2012 04:06:50 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 126049689; Fri, 3 Aug 2012 04:06:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=nJ3Hre6JLGG8xYzue4RIXevhg0Q=; b=VkezgB /LvgTAb076EzzJPSU9DwaIXKbx6uJK8tYtkWMjd+FunPfEn4Hk/DraplgaVaLX8t 7FIm77plM317pjiyawfNK3xDh+syEtPMu5rOmQCGuolE27lCp7nPLTYsMoDc9RXr vtAwtePaBdroUIZZu/hAxQ47aLk/AKO4PCYRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=fQw33y/gp+iDoTtMLehhpMw3Or/Q2xpI 1cuxn0fmfi+pogEUhr0fYps1ukh2EGz0rxQ4+JSPW2iHe/1HPuRDCgvZzVzXB2Jw sfkHuY7trsHJXqhFN5CX6IBu1IqdGWJ8kV+smP9XRVkFPc8ambZSfoqLaQTzP3AS UvoC6mw/j1Y= Original-Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0065B9688; Fri, 3 Aug 2012 04:06:50 -0400 (EDT) Original-Received: from badger (unknown [91.117.99.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 7C4AA9687; Fri, 3 Aug 2012 04:06:49 -0400 (EDT) In-Reply-To: (Noah Lavine's message of "Thu, 2 Aug 2012 18:21:02 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) X-Pobox-Relay-ID: 2D5C823C-DD42-11E1-A7F9-11610E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 208.72.237.25 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:14768 Archived-At: Hi Noah, Thanks for the thoughts. On Fri 03 Aug 2012 00:21, Noah Lavine writes: > 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). It's a good idea; I have it in my local branch. Putting the MVRA before the call didn't work out because the call instruction is variable-length. > CALL: > call f > MVRA: > jump mv-handler > RA: > ... rest of function ... Yes and for a truncating return: CALL: call f MVRA: truncate RA: ... rest of function ... Native compilation should do something different though. But Mark's mail has more on that, so I'll reply there. Andy -- http://wingolog.org/