[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