[m-dev.] add goal path at external ports
fjh at cs.mu.OZ.AU
Sat Jan 30 15:08:13 AEDT 1999
On 29-Jan-1999, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> Fergus wrote:
> | > I would argue that the current line number at the time of a call is
> | > in the body of the *calling* procedure.
> | Well, I'd say that's a terminology issue. I'm talking about things
> | at the implementation level here. Each event is associated with
> | a particular procedure, and the "current line" for that event
> | should be a line in that procedure. In the current implementation,
> | "call" events occur in the called procedure, not in the caller,
> | so the line number must be one associated with the callee.
> | We could in theory define some new event types, called say "before-call",
> | "after-exit", "before-redo", and "after-fail", which would occur
> | in the caller rather than in the callee. (It would even be possible
> | to rename the existing call/exit/redo/fail events to something different
> | and rename the new before-call/after-exit/before-redo/after-fail
> | events as call/exit/redo/fail, but that would be a shift in terminology.)
> | However, doing so would be quite inefficient.
> What would be inefficient: remove the current call/exit/redo/fail events and
> replace them by your before-call/after-exit/before-redo/after-fail
> or adding
> before-call/after-exit/before-redo/after-fail to existing events ?
Adding those without removing call/exit/redo/fail would be even more
> If it is the later, I understand. But if it is the former, why is it
> inefficient ?
With call/exit/redo/fail, the generated code contains 2 or 3 calls to
MR_trace() per procedure. With before-call/after-exit/before-redo/after-fail,
the generated code would contain 2 or 3 calls to MR_trace() for each
call. Procedures usually contain more than one call, I believe,
so the latter would lead to increased code size and hence decreased locality,
decreased spead, and higher compilation time.
Fergus Henderson <fjh at cs.mu.oz.au> | "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh> | but source code lives forever"
PGP: finger fjh at 126.96.36.199 | -- leaked Microsoft memo.
More information about the developers