On 08/24/2012 05:00 AM, Steven D'Aprano wrote:
No. The compiler remembers the address of 'a' by keeping notes about it
somewhere in memory during the compilation process. When you run the
compiled program, there is no longer any reference to the name 'a'.
...
The mapping of name:address is part of the *compilation* process -- the
compiler knows that variable 'x' corresponds to location 12345678, but
the compiled code has no concept of anything called 'x'. It only knows
about locations. The source code 'x = 42' is compiled into something like
'store 42 into location 12345678'. (Locations may be absolute or
relative.)
In languages with name bindings, the compiler doesn't need to track
name:address pairs. The compiled application knows about names, but not
about addresses. The source code 'x = 42' is compiled into something like
'store 42 into the namespace using key "x"'.
What you describe is sorta correct, but it's also not... you're
describing implementations rather than the language. And while the
language semantics certainly impose restrictions on the implementation,
I think in this case the situation is closer than you acknowledge:
From the Python side, I suspect that for most functions, you'd be able
to create a Python implementation that behaves more like C, and
allocates locals in a more traditional fashion. I don't know much about
it, but I'd guess that PyPy already does something along this line;
someone also mentioned that Cython (admittedly not a full-blown Python
implementation, but close for the purpose of this question) tries to do
the same thing.
On the C side, imagine a function with locals x, y, and z which never
takes the address of any of them. (You said later that "Just because the
public interface of the language doesn't give you any way to view the
fixed locations of variables, doesn't mean that variables cease to have
fixed locations.")
First, C variables may not even have a memory address. They can
disappear completely during compilation, or live in a register for their
entire life.
Second, it's possible that those variables *don't* occupy a fixed
location. If you never explicitly take an address of a variable (&x),
then I can't think of any way that the address can be observed without
invoking undefined behavior -- and this means the C compiler is free to
transform it to anything that is equivalent under the C semantics. In
particular, it can split uses of a variable into multiple ones if there
are disjoint live ranges. For instance, in:
x = 5
print x
x = 10
print x
there are two live ranges of x, one consisting of lines 1 and 2, and one
consisting of lines 3 and 4. These live ranges could have been different
variables; I could just of easily have written
x = 5
print x
y = 10
print y
and these pieces of code are observationally equivalent, so the compiler
is allowed to generate the same code for both. In particular, it could
either compile the second example to share the same memory address for x
and y (meaning that a memory address isn't uniquely named by a single
variable) or it could compile the first to put the two live ranges of x
into different memory addresses (meaning that a variable doesn't
uniquely name a memory address). In fact, I'd *expect* an optimizing
compiler to share memory for x and y, and I'd also expect to be able to
concoct an example where different live ranges of one variable wind up
at different addresses. (The latter I'm less sure of though, and I also
expect it'd be a little hard, as you'd have to come up with an example
where even at the high optimization levels you'd need to see that, both
live ranges would wind up in memory.)
Third, and more wackily, you could technically create a C implementation
that works like Python, where it stores variables (whose addresses
aren't taken) in a dict keyed by name, and generates code that on a
variable access looks up the value by accessing that dict using the name
of the variable.
Evan
--
http://mail.python.org/mailman/listinfo/python-list
