From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Matthew Mundell Newsgroups: gmane.emacs.devel Subject: Re: Compilation to native Date: 13 Apr 2004 20:03:41 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87r7ur8zua.fsf@sno.mundell.ukfsn.org> References: <87eks0654s.fsf@sno.mundell.ukfsn.org> <87n06bp4ng.fsf@sno.mundell.ukfsn.org> <877jxccutf.fsf@sno.mundell.ukfsn.org> <87k712gesk.fsf@sno.mundell.ukfsn.org> <87k70lhrsq.fsf@sno.mundell.ukfsn.org> <87wu4jrf3j.fsf@sno.mundell.ukfsn.org> <87d66bg55g.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081883244 13595 80.91.224.253 (13 Apr 2004 19:07:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2004 19:07:24 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 13 21:07:14 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 1BDTFa-0006Cv-00 for ; Tue, 13 Apr 2004 21:07:14 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BDTFZ-0004dY-00 for ; Tue, 13 Apr 2004 21:07:14 +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 1BDTFT-0006Z6-RL for emacs-devel@quimby.gnus.org; Tue, 13 Apr 2004 15:07:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDTDj-0006Kc-Pp for emacs-devel@gnu.org; Tue, 13 Apr 2004 15:05:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDTD5-0005nA-W8 for emacs-devel@gnu.org; Tue, 13 Apr 2004 15:05:12 -0400 Original-Received: from [217.158.120.143] (helo=mail.ukfsn.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDTCC-0005GR-Pb; Tue, 13 Apr 2004 15:03:44 -0400 Original-Received: from localhost (lucy.ukfsn.org [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 2052CE6E9B; Tue, 13 Apr 2004 20:01:07 +0100 (BST) Original-Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (lucy.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00940-13; Tue, 13 Apr 2004 20:01:07 +0100 (BST) Original-Received: from sno.mundell.ukfsn.org (dsl213-218-238-16.as15444.net [213.218.238.16]) by mail.ukfsn.org (Postfix) with ESMTP id B868CE6D3F; Tue, 13 Apr 2004 20:01:06 +0100 (BST) Original-Received: from sno.mundell.ukfsn.org ([10.0.0.3]) by sno.mundell.ukfsn.org with esmtp (Exim 3.36 #1 (Debian)) id 1BDTCA-0000N2-00; Tue, 13 Apr 2004 20:03:42 +0100 Original-To: Stefan Monnier Original-Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:21592 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21592 Stefan Monnier writes: > >> > This optimisation more than doubles the speed of the generated > >> > function. The optimisation adds two new byte operations. As a start > >> > the new operations always take parameters that are four bytes wide. I > >> > think the loading of these four bytes is the cause of the slower byte > >> > interpretation. > >> I don't understand. Could you give us more info about what those new byte > >> ops are and what they're used for (and maybe why you think they make things > >> slower in the byte-interpreter, tho I should be able to figure that out on > >> my own at that point). > > The optimisation moves variable referencing and setting out of loops. > > Feel free to use precise words like `varref' or `varset'. We want/need > technical details here. Thanks. varrefs and varsets are moved out of loops. > > > The Lisp objects are instead referenced onto the stack before the > > loop, and set from the stack afterwards. The new operations are used > > You mean you added two byteops: one to read the Nth word on the stack > (counting from the top) and the other to set that word? I expect you > called them something like `sset' and `sref'? Yes. They're called stkref and stkset. stkref pushes a copy of the Nth Lisp_Object from the top of the stack onto the top of the stack. stkset sets the Nth Lisp_Object from the top of the stack. > Sounds generally useful (something similar is used in the `lexical' branch > of Miles, you might want to check that out). I've been verging on checking out his branch, but have been putting off learning arch, partly because the documentation is excluded from Debian, mostly because it looks like it'll take a while.