[m-dev.] add goal path at external ports

Fergus Henderson 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

Yes, that.

> 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        |     -- leaked Microsoft memo.

More information about the developers mailing list