From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: stop using P_, __P in header files Date: Tue, 06 Jul 2010 16:50:40 +0900 Message-ID: <87iq4t9hgv.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <165FCF5E-631E-44A3-8134-2E758F458434@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1278403577 8738 80.91.229.12 (6 Jul 2010 08:06:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Jul 2010 08:06:17 +0000 (UTC) Cc: dann@gnu.org, Eli Zaretskii , emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 06 10:06:14 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 1OW3AQ-0005zY-H1 for ged-emacs-devel@m.gmane.org; Tue, 06 Jul 2010 10:06:10 +0200 Original-Received: from localhost ([127.0.0.1]:40390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OW30p-0000Lz-81 for ged-emacs-devel@m.gmane.org; Tue, 06 Jul 2010 03:56:15 -0400 Original-Received: from [140.186.70.92] (port=42374 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OW30h-0000LI-1Q for emacs-devel@gnu.org; Tue, 06 Jul 2010 03:56:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OW30f-0000CC-DR for emacs-devel@gnu.org; Tue, 06 Jul 2010 03:56:06 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:45425) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OW30X-0008QF-GX; Tue, 06 Jul 2010 03:55:57 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 43717820D; Tue, 6 Jul 2010 16:55:54 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0BF241A291A; Tue, 6 Jul 2010 16:50:41 +0900 (JST) In-Reply-To: <165FCF5E-631E-44A3-8134-2E758F458434@raeburn.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 6466bc9ebf15 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:126826 Archived-At: Ken Raeburn writes: > 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, Agreed, but until it becomes standardized, that leads to really ugly code if you try to make things work across compilers. "register", on the other hand, is part of the language. > > 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 meant the number of variables to be allocated to registers. The principle is only interesting if there's a branch, and you care most about variables that are frequently accessed on one branch but not the other. So make that 4-5 registers being allocated; on x86, more than that number of register declarations doesn't help and could even hurt if the compiler respects the programmer's judgment too much. If you've got a lot of registers, then (for code written by humans, anyway), I don't think it likely you'd need to give the compiler much advice. > 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. Sure, I'd go so far as to say that "s/register //g" would be a great idea in that file. You did ask if "register" was *ever* useful, though. I'm sure the answer to that is still "yes". (I have to admit that after looking at data.c again, I'm completely in sympathy with compilers that count the number of register declarations and ignore all of them if there are more than one per hundred lines. :-) > And I suspect any significant fine-tuning with register > declarations is likely to be specific to an architecture and/or > compiler. For modern compilers, actually I would guess not, because I think the useful cases are limited to your "grudging admission", where the compiler truly can use a hint because the branch frequencies are data-dependent or something. That's not going to be compiler- dependent (assuming you don't opt for informing the compiler of branch frequencies). As for architecture, I'd say what a human programmer can do to give good advice is probably limited to x86 levels of register poverty, so more than 3 or 4 register declarations is probably not ever worth the effort (and will be a no-op on register- rich architectures, of course).