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: Register VM WIP Date: Wed, 16 May 2012 16:58:24 +0200 Message-ID: <87r4uki35b.fsf@pobox.com> References: <871umqr8q0.fsf@pobox.com> <873972zczy.fsf@gnu.org> <87bolpmgew.fsf@pobox.com> <871umkbvp3.fsf@netris.org> <87fwb0k35g.fsf@pobox.com> <87sjf09r5v.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1337180323 20829 80.91.229.3 (16 May 2012 14:58:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 May 2012 14:58:43 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed May 16 16:58:42 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 1SUfgX-0002OD-WC for guile-devel@m.gmane.org; Wed, 16 May 2012 16:58:42 +0200 Original-Received: from localhost ([::1]:60800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUfgX-0003qZ-DZ for guile-devel@m.gmane.org; Wed, 16 May 2012 10:58:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUfgT-0003qS-Ig for guile-devel@gnu.org; Wed, 16 May 2012 10:58:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUfgN-00043r-Vw for guile-devel@gnu.org; Wed, 16 May 2012 10:58:37 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:38801 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUfgN-000432-MZ; Wed, 16 May 2012 10:58:31 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 2F4D083D9; Wed, 16 May 2012 10:58:28 -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=1c70doEZCiIdK+i4hiqSAYMLAcE=; b=K7yWAk HOm1OdjDS6MHaI/QtyW/RBMj/Vs6qYCG+yt5m/6B1tuqQZFEL7SDebNTELh+jzLu EgO1HdbsFGfaP/XuWdUult5EXGnpkeigzuleoF+1xSYF6OdiEkqXA4YGFZ2VWoEH aqXcLeP+mRXP+NRMYfJ65byfjrzfotOSq8W2Y= 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=skXVc8h3z2EfQGxFZrwXe/1WT/fZyu5M Nj9DfKgEy04j9+7RzEyLajzwAAgvnubQT1oL20KiXSO9dkirIoZ/e9U1yTdC3WNT I9KJtrd5XlC4AsS0SnTV2/Cfe4N1NqZS8L3+ULc7g3ahHIiRx93gycS8fJKcsxQV X4gjsM2EWOc= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 22C3283D2; Wed, 16 May 2012 10:58:28 -0400 (EDT) Original-Received: from badger (unknown [85.50.188.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 4C90A83D0; Wed, 16 May 2012 10:58:27 -0400 (EDT) In-Reply-To: <87sjf09r5v.fsf@netris.org> (Mark H. Weaver's message of "Wed, 16 May 2012 09:44:28 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-Pobox-Relay-ID: 97C6A918-9F67-11E1-9846-E981AF15ED39-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 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:14467 Archived-At: Howdy, On Wed 16 May 2012 15:44, Mark H Weaver writes: >> The design of the wip-rtl VM is to allow 16M registers (24-bit >> addressing). However many instructions can just address 2**8 registers >> (8-bit addressing) or 2**12 registers (12-bit addressing). We will >> reserve registers 253 to 255 as temporaries. If you have so many >> registers as to need more than that, then you have to shuffle operands >> down into the temporaries. That's the plan, anyway. > > I'm very concerned about this design, for the same reason that I was > concerned about NaN-boxing on 32-bit platforms. Efficient use of memory > is extremely important on modern architectures, because of the vast (and > increasing) disparity between cache speed and RAM speed. If you can fit > the active set into the cache, that often makes a profound difference in > the speed of a program. > > I agree that with VMs, minimizing the number of dispatches is crucial, > but beyond a certain point, having more registers is not going to save > you any dispatches, because they will almost never be used anyway. > 2^12 registers is _far_ beyond that point. I'm probably not explaining myself clearly. Here goes. I willingly grant that 256 registers is usually enough. But there are valid reasons to use 2**12 registers: for example in the mov instruction, if you have an 8-bit opcode, you have 24 bits left. Using 12 for each operand makes sense. There are other cases in which you want to reference 24-bit values, for relative jumps; and even 32-bit values, to reference constants using relative addressing. (64 MB is too small a limit for one compilation unit. 16 GB is fine.) Likewise I can imagine cases in which you might end up with more than 2**12 active locals, especially in the presence of macros. In that case you spill. But where do you spill? For Guile, this means spilling to additional registers, and having to shuffle with long-mov. Otherwise you would spill to a vector or something. The WIP-RTL strategy adequately captures the edge case while making the normal case fast. > If I were designing this VM, I'd work hard to allow as many loops as > possible to run completely in the cache. That means that three things > have to fit into the cache together: the VM itself, the user loop code, > and the user data. IMO, the sum of these three things should be made as > small as possible. Certainly. > I certainly agree that we should have a generous number of registers, > but I suspect that the sweet spot for a VM is 256, because it enables > more compact dispatching code in the VM, and yet is more than enough to > allow a decent register allocator to generate good code. > > That's my educated guess anyway. Feel free to prove me wrong :) I will do better: I will prove you right and prove me right at the same time :) The instructions in wip-rtl try to stay in one 32-bit unit. In that case they have limits, usually 8 bits. But when they need to "spill", they will do so on the stack, not on the heap. Regards, Andy -- http://wingolog.org/