Re: Rewrite of PROPOSAL 001213.1 re default location

[Jim Dehnert <dehnert at transmeta dot com>]

Michael Eager wrote:
> 
> No, I don't think so.  It appears that the existing text of the
> standard would not be applicable in any circumsance, under your
> interpretation.  I see no reason to accept an interpretation
> of the existing standard which has no utility.

I don't think so.  I think the existing standard very clearly says what
Ron interprets it to say, and I also provided an example earlier today
of what immediately came to mind when I saw it.  It may well be that
this isn't what was intended, or what the "best" interpretation is from
a utility standpoint, but I think that if we want to claim that David's
interpretation is correct, a wording change is absolutely necessary.

But before we blithely do that, consider the following situation.
A subprogram parameter is passed in a register.  Shortly after entry,
it is stored to a memory location that is its "home."  However, it
remains live in the register for a while, until after being used in
an expression.  Later in the subprogram, there is one region (or more)
where it is transferred to a register, used and modified there, and
eventually stored back.

So we have one range near the entry where the value is live and valid
simultaneously in both places -- the debugger may read from either and
must write to both.  Later there are regions where the value is only
valid in the register, and the memory location may or may not even be
touchable (i.e. a compiler could have allocated something there
temporarily -- though admittedly stack memory allocation in the sense
of coloring and reallocation is something I've often heard suggested,
but never heard of being implemented).

So, if we want to use the current overlapping range mechanism to solve
Ron's issue, we need to clarify (a) which of the locations with
overlapping ranges contains the currently valid value for access -- I
would think first is the right answer, and (b) that all of the locations
with ranges overlapping the current address should be updated.  This (b)
would make it clear to implementors that actually did reallocate the
memory while the value was in a register that they must leave a hole
in the "default" range.  I don't think that's onerous, since I don't
think it'll be done much if at all, but I think it should be clear.
Given those "clarifications," I think the current mechanisms should be
adequate to Ron's purpose, but the current wording isn't.

Jim