From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Jaeyoun Chung Newsgroups: gmane.emacs.devel Subject: Re: threaded code in bytecode.c Date: Mon, 03 May 2004 13:15:38 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87vfjew3h1.fsf@jaylin.tmax.co.kr> References: <20040503011011.GA16378@people.kldp.org> <20040503013537.GA14217@fencepost> Reply-To: jay@kldp.org NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1083630099 5919 80.91.224.253 (4 May 2004 00:21:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 00:21:39 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 04 02:21:24 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKnga-0001xm-00 for ; Tue, 04 May 2004 02:21:24 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKngZ-0001zs-00 for ; Tue, 04 May 2004 02:21:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKndE-0003Yn-PE for emacs-devel@quimby.gnus.org; Mon, 03 May 2004 20:17:56 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKnbt-0003Jf-2i for emacs-devel@gnu.org; Mon, 03 May 2004 20:16:33 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKnbI-0003Dp-GA for emacs-devel@gnu.org; Mon, 03 May 2004 20:16:27 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1BKnbI-0003DD-82 for emacs-devel@gnu.org; Mon, 03 May 2004 20:15:56 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by mx20.gnu.org with esmtp (Exim 4.30) id 1BKnWK-0005UJ-DZ for emacs-devel@gnu.org; Mon, 03 May 2004 20:10:48 -0400 Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BKnWD-00054r-00 for ; Tue, 04 May 2004 02:10:41 +0200 Original-Received: from 210.216.114.55 ([210.216.114.55]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 May 2004 02:10:41 +0200 Original-Received: from jay by 210.216.114.55 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 May 2004 02:10:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 26 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 210.216.114.55 X-Face: (P/*J/`X8Z=]avkPZAtcu}m)~bBU'6="1{#v.ATtGoL-a"#CZvE^UK]R?tKS3)c(www${Bd kxv-_*2Kmj|X^kf.pW,@sMf{nb*%{x; 2/xGMKkB,j/seqT:2i4OFN>uK?sazKl"K5GiuPoMzh/i[eH ,6!@QgH!x:}2^o81d:vL-6PDaG_[L X-Url: http://kldp.org/~jay User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:9DZHRAxmrOtBniQdy8njqDVlwLw= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22668 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22668 * Miles Bader at 2004-05-02 21:35-0400 | On Mon, May 03, 2004 at 10:10:11AM +0900, jay@people.kldp.org wrote: >> I've just added gcc's computed goto based bytecode interpretation in >> bytecode.c without affecting any other parts. > | Does using this gcc extension make any noticeable speed difference? Well, I didn't checked it out but I'm sure it will. at least the dispatching overhead has been half-ed. After all, reducing the bytecode interpretation overhead worth trying. I really wanted to specify some register dedication for 'op' and `top' and a few other fields but didn't apply them yet since I don't know how to make it portable except for sparc and x86 machines. | BTW, your patch contains a lot of unnecessary reformatting &c of the | byte-code #defines (white space changes, replacing `foo + N' with `fooN'), | which makes the patch harder to read and will likely cause merge conflicts. well, i think realigning the number would be better for the readability. I'll not change the spaces so that spurious diffs does not bother developers. And converting 'foo + N' to fooN is a necessity to give it a label in case THREADED_CODE is defined. And also, I think it is more explicit than using the implicit '+ N' rule for those operator.