[m-dev.] for review: a big step towards the trace-based debugger (part 2 of 3)

[Zoltan Somogyi]

> > +% The live data pair vector will have an entry for each live variable.
> > +% The entry will give the location of the variable and its type. (It also
> > +% has room for its instantiation state, but this is not filled in yet.)
> > +%
> > +% The live data name vector pointer may be NULL. If it is not, the vector
> > +% will have an entry for each live variable, with each entry being either
> > +% NULL or giving the name of the variable.
> 
> In what cases will it be NULL?  What does that represent?

I have clarified what the individual entries being NULL means (variable
has no name). The entire vector being NULL is already explained further down.
(You can't explain everything all at once.)

> > +	{ Label = local(_, LabelNum0) ->
> > +		LabelNum = LabelNum0
> > +	;
> > +		LabelNum = -1
> > +	},
> 
> In what cases would LabelNum = -1 happen (operationally)?

If Label is the entry label. Tracing will not use such a label and neither
will it be a resumption point in unoptimized code, and I don't *think*
it can be made a resumption point by any optimization, but I can't prove
that right now.

> Should be documented, along with how the runtime should interpret this
> data.  Should be documented above too (I don't remember seeing it, but
> I could be wrong).

It is documented now.

> > @@ -49,7 +53,8 @@
> >  
> >  #define MR_DETISM_FIRST_SOLN(d)		(((d) & 8) != 0)
> >  
> > -#define MR_DETISM_DET_CODE_MODEL(d)	(((d) & 1) == 0)
> > +#define MR_DETISM_DET_CODE_MODEL(d)	(!MR_DETISM_AT_MOST_MANY(d) \
> > +					|| MR_DETISM_FIRST_SOLN(d))
> >  
> 
> But MR_DETISM_FIRST_SOLN is actually subsumed by !MR_DETISM_AT_MOST_MANY
> isn't it?

No. cc_* determinisms have AT_MOST_MANY. In any case, after Fergus's question,
I renamed the macro to indicate its true function: to indicate which stack
the procedure has its frame on. (Note that this function is needed only by agc,
not by tracing.)

Zoltan.