Re: stop using P_, __P in header files

["Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>]

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).