Re: Modifies vs. Replaces

[Jim Dehnert <dehnert at transmeta dot com>]

Michael Eager wrote:
> 
> I'll also note that there appears to be no harm to the program's
> execution by updating both the memory and register contents.

That's true, as long as the memory isn't used for something else in
the meantime (quite unlikely).  But it's important that the debugger
_read_ the value from the register -- the two locations aren't
equivalent for this purpose.  This was why I suggested, back during
the default value discussion, that a possible treatment was to say
that a designated element of a list of overlapping ranges (probably
the first, maybe the last) be considered primary for reference, but
that all must be updated.

This also copes well with a more problematic example I brought up at the
time.  Suppose again that you have a variable with an allocated memory
location.  A new value is assigned to it, and the following events occur:

	a:  x.reg = new value
	...
	b:  x.mem = x.reg (store to home location)
	...
	c:  ... = ... x.reg ...
	... x.reg is dead ...
	d:  load x.mem

Between points b and c, x is live in both the register and memory.  Its
value may be read by a debugger from either place, and must be updated
in both places.

So my personal bias for the rule we're discussing would be:

	The defining instance's global location is always potentially live,
	and must therefore be updated.

	The non-defining instance's location(s) take precedence for
	addresses within the specified range(s); only the first one
	encountered with the desired address in range is guaranteed
	to have a valid value for reference, but all must be updated.

This would effectively make the global location a default location, to
be used whenever there is no other matching address range.  It's a
compact representation, since the non-defining instances only need to
specify temporary locations that override the global one.  It does
require, though, that a debugger look up the defining instance even
if it finds a matching local non-defining one.

Jim

	
-- 
-	    Jim Dehnert		dehnert@transmeta.com
	    (408)919-6984	dehnertj@acm.org