[m-dev.] for review: generating C layout structures

[Zoltan Somogyi]

On 09-Jan-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> This double update problem needs to be at least documented at the top of
> dl.m

I have done that in both copies.

> but really we have to decide how we are going to fix it in the
> long term.

Fergus was going to fix it long ago, but I guess it fell off his stack.

> I'm wondering whether it would be possible to get the compiler to
> generate a genuine closure layout which dl.m could load.  If it has a
> known (that is, regularly mangled) symbol name then couldn't we
> reference it by dynamically loading it?  
> 
> I'm thinking that if you told the compiler that "somepredname" was an
> "entry point" it might generate a closure layout suitable for
> dynamically linking.

I will leave that for someone energetic enough to wonder about such things :-)

> > +** The MR_sll_var_count field, if it is valid, is encoded by the formula
> > +** (#Long << MR_SHORT_COUNT_BITS + #Short), where #Short is the number
> > +** data items whose descriptions fit into an MR_Short_Lval and #Long is the
> > +** number of data items whose descriptions do not. (The number of distinct
> > +** values that fit into a 8 bits also fits into 8 bits, but since some
> > +** locations hold the value of more than one variable at a time, not all
> > +** the values need to be distinct; this is why MR_SHORT_COUNT_BITS is
> > +** more than 8.)
> 
> I don't really understand the parenthetical remark.  It seems to be
> missing a few words ("fit into a 8 bits also fits into 8 bits"?).

It seems to have an extra "a" in "a 8 bits", but it is otherwise lucid to me;
the relevant sentence structure is

(The number of (distinct values that fit into 8 bits)) (also fits into 8 bits)

> Does this max 16 bit number mean very bad things have happened?

Except for having waited forever for compilation, no.

I followed your other suggestions.

Zoltan.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------