[m-dev.] Re: retrieving arguments in the trace

[Zoltan Somogyi]

I wrote:
> Keeping the stack frame live until the exit or fail trace is not a
> problem; with the current tracing code, you already always have the
> stack frame when you call any of the trace functions (provided the
> procedure has a stack frame at all;
> some don't).

Erwan and Mireille wrote:
> What are thoses procedures ?

The code generator always creates a stack frame for all procedures.
However, the optimizer tries to delay the creation of the stack frame
as long as possible, and sometimes it can get rid of the stack frame
altogether. In general, any procedure that makes no calls except possibly
a tail call will have its stack frame eliminated by the optimizer.

We can of course turn off the optimizations that do this if necessary.

Erwan and Mireille wrote:
> Actually, the current idea is to keep the low-level tracer as cheap
> and simple as possible. In a first stage we will work with the
> information about the live variables at "call" and "exit" times (and
> anymore information you can cheaply get). We will try to reconstruct
> the rest of the information within Opium with Prolog or Mercury
> programs. It should be possible (at what cost, is another question).
> 
> Let us know when this runtime information is available.

On Sunday, Tyson committed a change that is a big step towards making
the info available.

Erwan and Mireille wrote:
> We have a request: do *not* pass the entire information as a parameter
> of the trace function. Instead we would rather have another function at
> our disposal so that we can get this information upon demand.

What we plan to do is to pass the trace function a pointer to an entry
in a table. The trace function can then look up whatever information it
pleases in the table entry.

Erwan and Mireille wrote:
> The trace function could have a further argument that, for exemple,
> would tell the ranks in the clause of the currently live variables and
> an extra function (like get-current-live-var-value(Rank) -> Value)
> would enable us to get the values if needed. I suppose we need to know
> the type at some point but if we know the rank of the variable we can
> deduce its type from static information (??).

I am not sure I know what you mean by "rank". If you mean the identity of
the variable, the compiler identifies variables by small integers (variable
names are not unique, because two occurrences of the same name in two
parallel contexts (e.g. two different clauses) conceptually refer to
two different variables.

The compiler knows the types of all variables, but these types may include
type variables. E.g. when processing append, it may know that a given variable
is of type T while another variable is of type list(T), but it would not know
what type T is, since T can be different on different calls. This is why the
compiler adds invisible extra arguments to polymorphic predicates, one extra
argument per type variable in the signature of the predicate. The caller will
fill in these extra argument with a description of the actual type denoted
by the corresponding type variable on that call.

I am also not sure what you mean by "currently live variables". At call,
these will be the inputs; at exit, these will be the outputs; at fail,
this will be the empty set. Do you need access to the values of variables
at entries to disjunctions, switch arms, then parts and else parts?

Zoltan.