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: wip-rtl return location Date: Thu, 02 Aug 2012 16:29:49 +0200 Message-ID: <87mx2dv02q.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1343917812 15861 80.91.229.3 (2 Aug 2012 14:30:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2012 14:30:12 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Aug 02 16:30: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 1SwwPi-0001oM-6c for guile-devel@m.gmane.org; Thu, 02 Aug 2012 16:30:10 +0200 Original-Received: from localhost ([::1]:53249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwwPg-0006aW-Ny for guile-devel@m.gmane.org; Thu, 02 Aug 2012 10:30:08 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwwPd-0006Yb-On for guile-devel@gnu.org; Thu, 02 Aug 2012 10:30:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwwPb-0004vT-4l for guile-devel@gnu.org; Thu, 02 Aug 2012 10:30:05 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:53929 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwwPZ-0004ro-Om for guile-devel@gnu.org; Thu, 02 Aug 2012 10:30:03 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D696C97DB for ; Thu, 2 Aug 2012 10:29:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:date:message-id:mime-version:content-type; s=sasl; bh=8 oy3/1w8UDglbAmsDfTk4ul1HrI=; b=mPnQc6ttXi5fp+0b5dIIDyLiexIm2Vz7H 2YaPD5hqIAdqGrBp74KqGo8wYpcyC/u0R3M0vwgHJK5MEJe2jxSqIGxjHn13M2g4 FznIz2t222R5ah5Vp/mS/lVzAlg87IrXdpY2S5xGR4jNY9FFNb7VIxhWq8yqFET6 Ac8tCYcXek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :date:message-id:mime-version:content-type; q=dns; s=sasl; b=JO3 qjF1I8ENfz8D/J5obvp3r5If7a0dfxEWNATAdAUwSpsiGDpqjk3csNDedTdaAI9f YHH/wtcPU4kNlNx+Lyo7A5TaODubqEiJrBLt715GtDLeGaZ02S5QQPT7uyN+Sua0 FBII2hruKpfVsuh+68o8carBSlOHb4uS4WpjZKe8= 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 C3BAF97DA for ; Thu, 2 Aug 2012 10:29:53 -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 0A24297D8 for ; Thu, 2 Aug 2012 10:29:52 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) X-Pobox-Relay-ID: 863240DE-DCAE-11E1-BE3D-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:14765 Archived-At: 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/