[m-dev.] For review: Using MR_TypeCtorInfo for generated type_ctor_infos

Zoltan Somogyi zs at cs.mu.OZ.AU
Fri Aug 6 15:02:26 AEST 1999

> Previously, the compiler assumed that the arguments of a type_ctor_info
> struct were all `Word'; this is indicated by the `uniform(no)' in the
> following code
>       DataName = type_ctor(info, TypeName, TypeArity),
>       CModule = comp_gen_c_data(ModuleName, DataName, Exported,
> 		      [ArityArg | FinalArgs], uniform(no), Procs),
> from line 175 of base_type_info.m.

This is incorrect in detail, although the idea is correct. uniform(no)
indicates that for all arguments, output_cons_arg_types in llds_out.m
will derive the type from the value of the argument itself.

> By changing the definition of the type_ctor_info struct without changing
> this `uniform(no)', you broke (1).  This is what caused the compiler warning
> Your proposed fix to insert a cast in the generated code for `string_consts'
> without changing llds_const_type/2 accordingly breaks (2).

> I think a fix which maintained invariants (1) and (2) would be better
> than your proposed change.

> The right way to fix this, I think, would be to modify line 175 of
> base_type_info.m so that it specifies the correct field types for a
> type_ctor_info; if you do that, then I think llds_out.m will insert
> the correct casts without you needing to do anything more.

I agree that this is the right fix. The right value to substitute for
uniform(no) is

	initial([1 - integer,
		3 - code_ptr,
		1 - XXX
		2 - data_ptr
		2 - string], none)

The XXX represents the llds_type of the representation field. If C compilers
are guaranteed to accept an initialization of a struct field whose type is
an enum with an int, then setting XXX = int will do. If not, then we need to
add a new alternative to llds_type, say enum(string), where the string is
the name of the enum type, and set XXX to enum("MR_TypeCtorRepresentation").
The code in llds_out ought to then put in the cast automatically, which I
believe ought always be legal. Fergus?

I am also not sure that we won't get warnings if we cast small integers to
the Word * type of the layout and functors fields. With the old type_ctor
design, I know this was required, but I don't know if the new type_ctor design
still requires this. Tyson?

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