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: [Guile-commits] GNU Guile branch, master, updated. a9b0f876c12bbbca9bdf1890eb014a30f004d9f8 Date: Sun, 07 Jun 2009 19:32:34 +0200 Message-ID: References: <87ab4molya.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1244395966 31113 80.91.229.12 (7 Jun 2009 17:32:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jun 2009 17:32:46 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jun 07 19:32:41 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MDMEa-0001Pr-SN for guile-devel@m.gmane.org; Sun, 07 Jun 2009 19:32:41 +0200 Original-Received: from localhost ([127.0.0.1]:43529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDMEZ-0004hv-Nn for guile-devel@m.gmane.org; Sun, 07 Jun 2009 13:32:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDMES-0004fK-0I for guile-devel@gnu.org; Sun, 07 Jun 2009 13:32:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDMEN-0004UQ-3l for guile-devel@gnu.org; Sun, 07 Jun 2009 13:32:31 -0400 Original-Received: from [199.232.76.173] (port=53344 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDMEM-0004U0-Rr for guile-devel@gnu.org; Sun, 07 Jun 2009 13:32:26 -0400 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:47460 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDMEJ-0001Vh-QT; Sun, 07 Jun 2009 13:32:23 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id EAEAE1DB57; Sun, 7 Jun 2009 13:32:21 -0400 (EDT) Original-Received: from unquote (unknown [83.32.70.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 3A3771DB56; Sun, 7 Jun 2009 13:32:20 -0400 (EDT) In-Reply-To: <87ab4molya.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Fri, 05 Jun 2009 15:21:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 284DDCDC-5389-11DE-AF9A-B5D1A546830D-02397024!a-sasl-quonix.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8643 Archived-At: On Fri 05 Jun 2009 15:21, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Hello! > > "Andy Wingo" writes: > >> @deffn Instruction object-ref n >> -Push @var{n}th value from the current program's object vector. >> +@deffnx Instruction long-object-ref n >> +Push @var{n}th value from the current program's object vector. The >> +``long'' variant has a 16-bit index instead of an 8-bit index. >> @end deffn > > Good that you fixed it! However, I'm wondering whether it's really a > good idea to keep both the long and short instruction variants, instead > of having a single 16-bit variant. What do you think? The 8-bit cases are more common, leading to less code size, and hopefully more cache hits. But see below... >> +VM_DEFINE_INSTRUCTION (52, long_object_ref, "long-object-ref", 2, 0, 1) >> +{ >> + unsigned int objnum =3D FETCH (); >> + objnum <<=3D 8; >> + objnum +=3D FETCH (); > > Perhaps a FETCH32() macro would actually be handy, and possibly more > efficient on platforms with 32-bit GP registers. > > Actually, it would be even better if OBJNUM was encoded as part of the > instruction, since it would reside on the same cache line as the > instruction that's just been read. It'd look like: > > #v+ > objnum =3D ((* (ip - 1)) & ~SCM_VM_INSTRUCTION_MASK) > >> SCM_VM_INSTRUCTION_MASK_LOG2; > #v- Well, if you were to do this, you would want aligned, word-sized instructions. This might be the right thing but I am not convinced, as it would double or quadruple the size of the code, thus increasing cache pressure. Java's bytecode is one byte in width, Lua's is too, Self's was one byte wide, ... I don't know I guess is my perspective. I'd be interested in checking this out, but it would take a few days, and I'm trying to focus on broad correctness, then we could analyze such a change with regards to benchmarks. > Also, I've forgotten about the details, but I was expecting one of the > fields in `scm_objcode' to become 16-bit after this change. Probably > I'm just confused? :-) Yes you are confused :) The object table is stored in a Scheme vector. Cheers, Andy --=20 http://wingolog.org/