Can someone explain how this apparent magic happens

["David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>]

    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. 

This is because the 3600 machine keeps a copy of the original arguments
in another place in the stack, and the debugger knows how to find them
and print them out.  This copy of the arguments is not normally
accessible to the called function.  This wasn't done to make the
debugger more featureful, it was done to speed up function calling
(why it speeds it up is too hard to explain over the mail).

Good sources of information on the 3600 architecture at this level of
detail are my articles in the January 1987 issue of IEEE Computer and in
112th International Symposium on Computer Architecture0, IEEE Computer
Society Press, 1985, pp. 76-83.
    
    ....
    What I want to know in particular, is if I muck arround and
    access stack frames via: SYS:%STACK-FRAME-POINTER and
    DBG:FRAME-PREVIOUS-FRAME and then get a locative to a slot
    in a stack frame via:
    
    (SETQ BAR-LOCATION
	  (SYS:%MAKE-POINTER-OFFSET SYS:DTP-LOCATIVE FRAME-OF-INTEREST 0))
    
    where I know that in the FRAME-OF-INTEREST the desired argument
    (say BAR as in the above example) is in slot 0 then does
    BAR-LOCATION point to "Arg 0" or to "Local 0" i.e. BAZ or QUUX?

The local.

    Please don't warn me that I am going to lose by mucking arround
    with stack frames, there is a very compelling reason why I am
    doing so. I understand that my code won't work on future machines
    and under future releases but I still want to do what I am
    doing.

Thank you for saving me the trouble of telling you that.  If this was
guaranteed to work, it would be documented.  I think you can tell from
the published articles on the Ivory chip, such as the one in IEEE
Transactions on Computers, that Ivory-based machines do not work the
same way and will not run your code if you use these subprimitives.
(Ivory is compatible for all the documented interfaces.)  In particular,
Ivory does not keep a copy of the original arguments around.  This was
done to speed up function calling (why it speeds it up is too hard to
explain over the mail).  Why optimizing function call resulted in
differences between 3600 and Ivory has to do with the differences in
implementation tradeoffs between 1983 technology and 1988 technology.
Fortunately, only the compiler and the debugger care about these details.