Path: utzoo!utgpu!watserv1!watmath!att!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: May too many register variables hurt?
Message-ID: <14567@smoke.brl.mil>
Date: 24 Nov 90 19:05:49 GMT
References: <967@mwtech.UUCP> <14538@smoke.brl.mil> <972@mwtech.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 33

In article <972@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>	... only the first few of such declarations are effective ...

Clearly what was meant by this is that only the first few OF THOSE CURRENTLY
IN SCOPE are effective.  Out-of-scope declarations are simply irrelevant.

As you note, the programmer has a hard time indicating which variables
are most important to registerize, when a variety of compilation
environments must be accommodated.  What some developers have done is
to add a batch of macros in their system-configuration header:
	/* Prioritized "register" declarations: */
	#define	REG_0	register
	#define	REG_1	register	/* last available for 6809 */
	#define	REG_2	register	/* last available for PDP-11 */
	#define	REG_3	/* nothing */
	#define	REG_4	/* nothing */
and in the application use these in a mutually-exclusive manner:
	func()	{
		REG_2 int	i;
		REG_0 char	*p;
		...
			{
			REG_1 char	*q;
			REG_3 int	j;
			...
			}
		}
so that no more "register" storage-class specifiers are seen by the
compiler in any scope than are actually effective for the implementation.

I don't use this method myself, preferring to use "register" as a hint
rather than a requirement, but if you are hyper-concerned about this
level of optimization you might want to consider such an approach.