Re: Support for Meta-Programming

[Michael van Acken <Michael.van.Acken@de.uu.net>]

Mike Griebling <grieblm@trt.allied.com> writes:

> > A procedure's local stack frame produced by any OOC compiler (not just
> > oo2c) has little resemblance with the procedure variables declared in
> > the source code.  Some variables disappear in the "assembler" output,
> > they only exists as intermediate results of calculations in
> > registers.  Also, there is no guarantee whatsoever what a variable
> > (which is stored in the stack frame) contains at a given point in
> > time.  A post-mortem-debugger would not know if the currently stored
> > value is valid.  Note that these restrictions do not hold for
> > variables that are not private to a procedure.  Global variables and
> > heap objects can be accessed without these limitations -- as long no
> > one adds a fancy optimization that optimizes them away ;-)
> 
> One would need to guarantee that variables are not optimized away.
> In other words, all variable optimizations would have to be disabled
> and all variables stored on the stack.  A debug flag should be enough
> to do this.  I'm not sure how much OOC depends internally on variables
> being in registers.

This is not possible.  On GSA level there is no information about the
local variables of scalar type as declared in the source code.  Data
flow through these variables is completely unravelled.  Normally any
assignments (in the source) to these variables have no effect on
memory (in the program).  Only for per reference argument passing (and
nonlocal access from nested procedures) local scalar variables are
kept in memory at all.

Note that this is not an optimization issue.  This happens even if all
optimizations are turned off.

-- mva