Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!jarthur!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.misc Subject: Re: Common subexpression optimization Summary: most common languages are heavvvvily aliased. Too bad. Message-ID: Date: 5 Feb 90 16:32:52 GMT References: <14225@lambda.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 93 In-reply-to: jlg@lambda.UUCP's message of 2 Feb 90 02:08:23 GMT 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