[m-dev.] for review: cleanup of tabling

Fergus Henderson fjh at cs.mu.OZ.AU
Thu Dec 30 19:20:44 AEDT 1999


On 30-Dec-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > > runtime/mercury_tabling_macros.h:
> > >     This new file contains macros that used to be part of the file
> > >     mercury_tabling.h. The macros call the functions defined in
> > >     mercury_tabling.c, but they also optionally print debugging messages.
> >
> > What's the rationale for moving these macros into a different header file?
> 
> Reducing clutter.

Hmm, I don't see how it would have that effect.
But I suppose it doesn't matter much.

> > > -typedef enum {
> > > -   MR_SIMPLETABLE_UNINITIALIZED,
> > > -   MR_SIMPLETABLE_WORKING,
> > > -   MR_SIMPLETABLE_FAILED,
> > > -   MR_SIMPLETABLE_SUCCEEDED
> > > -} MR_SimpletableStatus;
> > > +#define    MR_SIMPLETABLE_UNINITIALIZED    0
> > > +#define    MR_SIMPLETABLE_WORKING          1
> > > +#define    MR_SIMPLETABLE_FAILED           2
> > > +#define    MR_SIMPLETABLE_SUCCEEDED        3
> >
> > What's the rationale for that change?
> 
> That fact that enums wouldn't work, since you cannot guarantee how much memory
> the compiler allocates for them.

Why not use

	enum {
	   MR_SIMPLETABLE_UNINITIALIZED,
	   MR_SIMPLETABLE_WORKING,
	   MR_SIMPLETABLE_FAILED,
	   MR_SIMPLETABLE_SUCCEEDED
	};
	typedef Integer MR_SimpletableStatus;

?

> > That comment seems to assume that floating point arguments will be boxed,
> > which is not true for the MLDS back-end.  The comment should be clarified
> > so that it is clear whether it is making that assumption and so that
> > it is clear whether it applies only to the LLDS back-end or to all
> > back-ends.
> 
> I presumed that tabling was not even supposed to work for the MLDS. Was I
> wrong?

Well, currently there are still quite a few things that don't work for the
MLDS.  Tabling does not yet work for the MLDS.  But that is likely to change
soon.

> Memoization and loop check could possibly be made to work for MLDS, after
> a lot of work has been put into eliminating the assumptions currently built in
> (e.g. all arguments are Word sized) that are not true for the MLDS.

I don't think that assumption is really built in.
I think making `pragma memo' and `pragma loop_check' work for the
MLDS back-end should be quite easy.  I tried a test case, and
it currently reports a "sorry, not yet implemented" error in
mlds_to_c.m, but the HLDS->MLDS code generation stage worked fine.

> However,
> minimal model tabling for MLDS is at least a major research project

I'm not sure whether it warrants the adjective "major", but yes,
certainly that would require research.

> For the time being I will try not to introduce new things that will prevent
> the application of loopcheck and memo to MLDS, but I will not go out of my way
> to fix existing things that do not work for MLDS.

That sounds fine.

> When can I expect a review of the rest of the change?

I'm on holidays from Christmas until about Jan 5th.
And I leave for the US on Jan 8th.
I'm not sure if I will have time before then.
I'll review it if I can find time, but no guarantees.
So if you want a timely review, I suggest you ask someone else ;-)

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list