From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? (Was: Are there plans for a multi-threaded Emacs?) Date: 10 Dec 2003 02:41:22 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20031117040607.C6C5D79B72@server2.messagingengine.com> <87ekvpx18d.fsf@emptyhost.emptydomain.de> <4nad6cikxy.fsf@holmes.bwh.harvard.edu> <4nllpt3hr3.fsf@lockgroove.bwh.harvard.edu> <5bad69zd43.fsf@lister.roxen.com> <4noeuon378.fsf@lockgroove.bwh.harvard.edu> <4ny8tsgxy6.fsf@lockgroove.bwh.harvard.edu> <4nhe0ggv0u.fsf@lockgroove.bwh.harvard.edu> <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> <4nsmjv8d32.fsf@collins.bwh.harvard.edu> <4nu14b6q33.fsf@collins.bwh.harvard. NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071020582 11153 80.91.224.253 (10 Dec 2003 01:43:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 10 Dec 2003 01:43:02 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Dec 10 02:42:57 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATtNR-00078e-00 for ; Wed, 10 Dec 2003 02:42:57 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATtNR-000558-00 for ; Wed, 10 Dec 2003 02:42:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATuK5-0006gv-9k for emacs-devel@quimby.gnus.org; Tue, 09 Dec 2003 21:43:33 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATuJz-0006f2-DX for emacs-devel@gnu.org; Tue, 09 Dec 2003 21:43:27 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATuJT-000650-B8 for emacs-devel@gnu.org; Tue, 09 Dec 2003 21:43:26 -0500 Original-Received: from [217.80.157.180] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ATuJS-00061o-JS for emacs-devel@gnu.org; Tue, 09 Dec 2003 21:42:55 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hBA1fPDn005093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2003 02:41:26 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hBA1fNh2005089; Wed, 10 Dec 2003 02:41:23 +0100 Original-To: Stefan Monnier In-Reply-To: Original-Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 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:18596 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18596 Stefan Monnier writes: > > Do you have an idea what figure we are speaking about here? I > > repeat: _every_ access to a symbol that now works directly instead > > has to work via stack pointers. And CPUs like the x86 do not have > > spare address registers flying around. > > I wouldn't worry too much about speed: there's lots of room for > optimization in the interpreter. The problem I see is one of > semantics because looking up bindings in the stack doesn't seem to > work so great when you take into account interaction with > buffer-local variables. That is: it tends to give you subtly > different semantics than the current one. Actually, considering the warnings in the manual about the necessary orders of exception-catchers and buffer switches and let and similar, I would expect that the different semantics would in most cases be rather an advantage (and what the programmer would have expected naively in the first place). A basically static variable allocation that gets saved and restored on a stack is more prone to surprising side effects than a straightforward stack. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum