[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Can someone explain how this apparent magic happens
Date: Thu, 18 Aug 88 01:20 PDT
I noticed that when you call a function say FOO which has
an argument BAR and you look at FOO's stack frame in the
debugger then BAR appears as a "Arg" slot in the stack frame.
But if you later SETQ BAR to something else and then do a
m-L in the debugger there are actually two entries for
BAR, the first labeled "Arg" with the original value passed
as a parameter, and the second labeled "Local" with the
the new value just SETQed. If I access BAR, of course I
get the new "Local" value. According to the naive expectation
of what the system is doing, I would have though that
a SETQ to an argument would simply overwrite the old value.
But how (and why) does the system retain the original
value and how does the system know how to get the old vs.
the new value when I access BAR depending upon whether
I have SETQed it?
Arguments are actually stored in TWO places. When a caller is preparing
to make a call, it pushes the arguments onto the top of the stack, so
they are at the end of the caller's stack frame. When the callee is
entered, the arguments are copied into his stack frame. This is so that
functions with variable numbers of arguments can always reference their
arguments as offsets from a known place in the stack frame (another
solution would have been to have an Argument Pointer register, but that
is not what they did).
When a function (or the debugger) references or sets an argument
variable, it is accessing the one in the local stack frame. The
debugger is nice enough, however, to show both versions of an argument
in the stack display when they are not the same.