[m-dev.] for review: one-arg MR_trace

[Tyson Dowd]

On 08-Dec-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> For Tyson to review.
> 
> WARNING: this change affects binary compatibility for debuggable code;
> the debuggable modules of the program and the runtime linked into the
> executable must either all come from before this change, or they must all
> come from after this change. However, this change does *not* affect binary
> compatibility for non-debuggable executables.
> 
> Reduce the number of arguments of MR_trace() to one. Two of the arguments,
> the port and the goal path, move into the label layout structure, as 16-bit
> numbers; the port as a simple enumeration type, and the goal path as an
> index into the module-wide string table. (The latter will eventually allow the
> debugger to support the placement of breakpoints on labels with specific goal
> paths.) The third argument, the number of the highest-numbered rN register in
> use at the label, has been moved into the proc layout structure. In theory,
> this will require more register saves and restores, since the number in the
> proc layout is conservative (it is the max of the numbers that would be
> required at the individual labels). However, this is not important, for two
> reasons. First, we always save and restore all the rM registers that
> appear in the mrM array before the last special-purpose register, and in
> most cases this dictates how many registers we save/restore. Second, we
> save/restore registers only when the debugger starts interaction, so
> save/restore is a time critical activity only for the external debugger.
> 
> This change reduces the execution time of debuggable executables by about
> 4-5% when executing outside mdb and 3-4% when executing under mdb. It also
> reduces executable sizes, but only by about 0.7% on x86.
> 
> This change eliminates the --trace-just-in-case compiler option, since
> we now have the best of both --trace-just-in-case and --no-trace-just-in-case.
> 
> The drawback of this scheme is slightly increased executable size with the
> accurage garbage collector, but that seems a small enough price to pay.


This change seems fine, and the results are good.  I'm not sure whether
this should wait for the feature freeze to be over -- this is not an
essential bug fix, and it might introduce new problems before the
release.  Fergus is the final arbiter on the matter, however.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't eveyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------