From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: indirect threading for bytecode interpreter Date: Fri, 18 Sep 2009 00:48:13 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1253227771 5413 80.91.229.12 (17 Sep 2009 22:49:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Sep 2009 22:49:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 18 00:49:25 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MoPn2-0003R0-CA for ged-emacs-devel@m.gmane.org; Fri, 18 Sep 2009 00:49:24 +0200 Original-Received: from localhost ([127.0.0.1]:43378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MoPn1-0006An-Qw for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2009 18:49:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MoPmQ-0005lr-9V for emacs-devel@gnu.org; Thu, 17 Sep 2009 18:48:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MoPmL-0005gD-Df for emacs-devel@gnu.org; Thu, 17 Sep 2009 18:48:45 -0400 Original-Received: from [199.232.76.173] (port=35196 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MoPmL-0005g0-72 for emacs-devel@gnu.org; Thu, 17 Sep 2009 18:48:41 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:34505) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MoPmK-0005Zf-PT for emacs-devel@gnu.org; Thu, 17 Sep 2009 18:48:40 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1MoPmH-0003By-Ga for emacs-devel@gnu.org; Fri, 18 Sep 2009 00:48:37 +0200 Original-Received: from 212.46.176.32 ([212.46.176.32]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Sep 2009 00:48:37 +0200 Original-Received: from eller.helmut by 212.46.176.32 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Sep 2009 00:48:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 37 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 212.46.176.32 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:l0hZfAcSXYLAicE+S6SLoTs5EHc= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115444 Archived-At: * Tom Tromey [2009-09-17 23:06+0200] writes: >>>>>> "Helmut" == Helmut Eller writes: > > Helmut> 5% doesn't sound like a lot to some people. > > Shrug. Obviously I think the tradeoff is worth it, or I would not have > sent the patch. I don't think the result is all that ugly. And, > importantly, it is very low-hanging fruit. I just expressed my opinion. I'm not the one to decide those issues. > Helmut> vmgen sounds like a good idea, but I fear that it makes the build > Helmut> process quite a bit more complicated. > > You can check in the generated code. vmgen generates quite a few files, though. > vmgen is a nice idea. I rejected writing this as a direct-threaded > interpreter because I assumed that the added memory use would be a bad > tradeoff. But, if you are interested in that, perhaps I could take a > stab at it. Yes, sounds a bit expensive memory-wise. Especially on 64-bit machines. > Helmut> I'm wondering why gcc can't perform this transformation from the > Helmut> switch based code. Is there no compiler setting to skip the > Helmut> range check in the switch statement? > > It isn't about range checking but about eliminating a jump during the > dispatch. You mean the shared NEXT vs. copied NEXT issue. Agreed, gcc can't figure that out easily. Helmut