From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: stop using P_, __P in header files Date: Tue, 6 Jul 2010 02:37:12 -0400 Message-ID: <165FCF5E-631E-44A3-8134-2E758F458434@raeburn.org> References: <4C2DB1E0.7010305@swipnet.se> <83aaqa9ml7.fsf@gnu.org> <9A690AC5-8C59-4691-88AC-EDDABCF2F704@raeburn.org> <83ocem8w6i.fsf@gnu.org> <87vd8t9qmr.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1278398272 25134 80.91.229.12 (6 Jul 2010 06:37:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Jul 2010 06:37:52 +0000 (UTC) Cc: dann@gnu.org, Eli Zaretskii , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 06 08:37:49 2010 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.69) (envelope-from ) id 1OW1mu-0007HU-02 for ged-emacs-devel@m.gmane.org; Tue, 06 Jul 2010 08:37:48 +0200 Original-Received: from localhost ([127.0.0.1]:50722 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OW1ms-0001ih-9L for ged-emacs-devel@m.gmane.org; Tue, 06 Jul 2010 02:37:46 -0400 Original-Received: from [140.186.70.92] (port=38354 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OW1mg-0001fh-Lc for emacs-devel@gnu.org; Tue, 06 Jul 2010 02:37:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OW1mf-00037Q-Hq for emacs-devel@gnu.org; Tue, 06 Jul 2010 02:37:34 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:37162 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OW1mN-00035E-Rv; Tue, 06 Jul 2010 02:37:33 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o666bCPA006744; Tue, 6 Jul 2010 02:37:14 -0400 (EDT) In-Reply-To: <87vd8t9qmr.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Apple Mail (2.1081) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:126824 Archived-At: On Jul 6, 2010, at 00:32, Stephen J. Turnbull wrote: > In principle, "register" is still occasionally useful. If you have a > large number of variables in a loop which has two long branches, then > which variables belong in registers depend on which branch is taken > more often, something that the compiler cannot know. If the compiler pays attention to them, yes, it could help. Though for = reasons other than register allocation it's probably more useful to tell = the compiler which branches are taken most often, though unfortunately = that's still compiler-specific (e.g., __builtin_expect, or feedback from = profiling runs). > Also, "large" depends on the number of registers available, of course. > In the case of x86, "large" is pretty small, about 8-10 IIRC. Fewer -- x86 has 8 integer registers including stack pointer and frame = pointer, and some are clobbered in function calls. Slap too many = "register" declarations onto variables and the compiler is still going = to have to guess which of them should actually be heeded. But if you = keep the number small, you can't give the compiler much advice on x86-64 = or ppc or other platforms with many more registers available. I will (grudgingly :-) admit there's sometimes a need to give the = compiler some hints that it can't necessarily work out for itself. But = I think the use of "register" in Emacs goes well beyond that, as I = pointed out regarding some functions in data.c. And I suspect any = significant fine-tuning with register declarations is likely to be = specific to an architecture and/or compiler. Ken=