Addresses of parameters (was Re: Portability of passing/operating ...)

[Tim Olson]

In article <35620 at XAIT.Xerox.COM> g-rh at XAIT.Xerox.COM (Richard Harter) writes:
| 	There are two reasons.  One is technical, the other is a matter
| of general principles.  The technical reason is that a calling sequence
| parameter need not have an address.  Consider a hypothetical machine P
| which passes the first n arguments through registers.  Taking the address
| of such an argument would then be equivalent to taking the address of a
| register.  I will grant that it is easy enough to put a kludge in the 
| compiler to get around this; any parameter whose address is referred to
| is copied onto the stack and that becomes the effective location.  But it
| is a kludge and there is no guarantee that the compiler writers will handle
| this for you (particularly in a a one pass compiler!)

You are correct: a calling sequence may stipulate that the first few
parameters are passed in registers instead of on the stack.  It is not,
however, a "kludge" to force this parameter out to memory if its address
is taken -- that is how it must work.  This is analogous to a compiler
which tries to keep local variables in registers, unless their address
is taken (i.e. ignore the "register" keyword).

| 	The reason that this is bad as a matter of general principles is
| that the address of a calling sequence parameter is not a meaningful
| thing.  Arguments in C are copies of the parameters passed.  The address
| (if it exists) is the address of the copy; it is not, so to speak, an
| address of a real object.  The general point is that calling sequence
| parameters are a different breed of cat from other variables.  Taking the
| address of a calling sequence parameter implicitly ignores one of the
| respects in which they are different.

How do you suppose varargs functions are implemented?  They must take
the address of the first parameter to "step through" the parameter list.
Are you suggesting that varargs functions are not portable and should be
avoided?


	-- Tim Olson
	Advanced Micro Devices
	(tim at crackle.amd.com)