Can someone explain how this apparent magic happens

[Barry Margolin <barmar@THINK.COM>]

    Date: Thu, 18 Aug 88 01:20 PDT
    From: Siskind.pa@xerox.com

    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.

                                                barmar