[m-dev.] for review: Accurate garbage collection.

Tyson Dowd trd at stimpy.cs.mu.oz.au
Thu Jul 2 20:20:10 AEST 1998


On 01-Jul-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 01-Jul-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> 
> > library/builtin.m:
> > library/mercury_builtin.m:
> > library/std_util.m:
> > runtime/mercury_tabling.h:
> > 	Deep copy terms using the address of the value instead of
> > 	just the value.
> ...
> > 	deep_copy (all variants) have been modified to take
> > 	a pointer to the data to be copied, because some variants
> > 	need to be able to modify it.
> 
> There are probably other calls to deep_copy() somewhere in extras/*.
> 
> I think it would be better to leave the interface to deep_copy()
> as is, if necessary by making deep_copy() a forwarding macro that
> calls the function that actually does the work.

Hmmm... There are problems.

If you make deep_copy a forwarding macro, 

#define deep_copy(X, ...)	deep_copy_internal(&X, ...)

you need to introduce a local variable, because deep_copy is sometimes
called with a register as an argument, and you can't take the address of
a register.

#define deep_copy(X, ...)	\
		{ Word local_value = X; deep_copy_internal(&X, ...) }

but this doesn't work, because deep_copy returns a value.

So you need to introduce a function.  Not a catastrophe, but it seems a
bit unnecessary.

Is there any driving need for this backwards compatability?  I think
deep_copy will be undergoing further changes in the future, so adding a
forwarding macro probably won't work for long anyway.

If there is a need, I can add a function and some XXXs mentioning that
this is only temporary.

-- 
       Tyson Dowd           # "Bill Gates is a white persian cat and a monocle
                            # away from becoming another James Bond villan."
     trd at cs.mu.oz.au        # "No Mr Bond, I expect you to upgrade."
http://www.cs.mu.oz.au/~trd #                -- Dennis Miller and Terri Branch



More information about the developers mailing list