🚀 go-pugleaf

In article <14225@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:

   > [... "register" attribute in C "a big win" ...]

   The only difference between a register variable and any other local
   variable in C is that you cant use the address-of (&) operator on
   register variables.

Well, there is also actually a strong *hint* that the variable will
be heavily *dynamically* used across statement boundaries, in the
current scope. The compiler can use this hint very effectively.

A careful programmer will never declare a variable for a scope larger
than that in which it is used, will never reuse a variable with the same
name for two different roles. Very few people don't do the sloppy
practice of declaring a bunch of variables at the beginning of a major
scope, some of which are aonly used in some section of it.

The compiler could do a liveness analysis on such variables, but
the source code remains obscure, because the source misrepresents to
the reader what goes on. The compiler or a human can second guess the
author, but this had better not happen, because it means the source is
not informative enough.

For example, when I heavvily use for a section of code a variable
that is otherwise little used, I will create a new scope for that
section of code, a register variable in it in which I will copy
the outer one, and copy back at the end of the paragraph. In this
way I am conveying both to human and compiler reading my code the
important information that I reckon that the variable is being
heavvily used. A human reader can find this information valuable
just as a compiler.

	Of course this is because I am eccentric enough to think
	that the performance characterization of a program is
	part of its design and pragmatics should be as obvious
	as semantics.

   In languages which don't have pointers (like
   Fortran 77) this is a moot distinction.  In languages in which
   pointers can only point to dynamic memory and are the only way to 
   do so (like Pascal and Modula2) this is also an irrelevant distinction.

Let me differ. Fortran has had equivalence and common forever,
and even if dirty tricks are prohibited in theory, most compilers
cannot assume users are well behaved (hey, most fortran programs
depend on subroutine local variables keep their values between
invocations!). Pascal has 'var' parameters, and, more murkly, variant
records without discriminant.

   In fact, the only use of the "register" attribute is to be able to
   declare variables that can't be aliased

While it is true that guaranteeing the absence of aliases makes
the compiler's job easier in caching variables safely across
statements, the two things are not related. The abominable
'noalias' (and the slightly less horrid 'volatile') proposed
extension to Classic C had the same purpose, but unsafe, in that
the absence of presence of 'noalias' (and 'volatile') does change the
semantics of a program, while for 'register' this is not true; 'register'
also gives a *positive* hint on usage frequency.

A compiler compiler could watch a function body for cases where a
variable address is not taken, and thus deduce the 'register'
attribute by itself. 'register' is better, because it allows one
pass compilation, and documents the assumptions made by the
author (e.g. frequency of usage) to both human and compiler.

With 'register' safety (no aliasing) is a side effect, but a
clever one, under more than one aspect.

   - an irrelevant distinction in MOST languages where variables
   have that property by default.

Actually I am hard pressed to think of widely adopted languages
with side effects in which variables can be safely assumed not to
be aliased. Aleph and Euclid come to mind, but not many more (I have
not thought about Ada, and the exact semantics of 'IN OUT' parameters).

What ruins the alias show for most languages is either separate compilation
or parameter passing, even where pointers are not present. And even if
this not true, the compiler still has to guess which of the safe variables
are actually worth caching.

	Naturally this is a moot point on many of today's architectures,
	where register optimization is entirely unnecessary, as there usually
	far more registers available than variables (unless you really have
	something like multiple threads, e.g. superscalar, or vector, but
	then you are really speaking of multiple register sets).
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk