[m-dev.] for review: MLDS back-end miscellaneous changes

[Tyson Dowd]

On 21-Apr-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Estimated hours taken: 12
> 
> More work on the MLDS back-end.
> 
> compiler/rtti_to_mlds.m:
> 	Pass the module_name of the current module down, so that we
> 	can use it for the module qualifier when generating references
> 	to type_info and higher_order_type_info rtti constants.
> 	Ensure that we output properly nested initializers for the
> 	union fields of type_ctor_infos.
> 
> compiler/mercury_compile.m:
> 	Pass the module_name to rtti_to_mlds.m.
> 
> compiler/mlds.m:
> 	Delete the obsolete type_ctor/3 data_name; this has been replaced by
> 	the rtti/2 data_name.  Also delete mlds__base_type_info_type, and
> 	instead add mlds__pseudo_type_info_type.
> 
> compiler/mlds_to_c.m:
> compiler/ml_unify_gen.m:
> 	Handle the changes to mlds.m.
> 
> runtime/mercury.h:
> 	Delete the obsolete MR_BaseTypeInfo type; we now use the
> 	MR_TypeCtorInfo_Struct type from mercury_type_info.h instead.
> 	Add typedefs for the various pointer and array types used
> 	for RTTI data structures; the MLDS->C back-end generates
> 	references to these typedefs.
> 
> runtime/mercury_type_info.h:
> 	Change the definitions of the MR_TypeCtorRep and MR_SecTag_Locn
> 	enumerations, so that they now define two names for each
> 	enumeration constant, one prefixed with
> 	`mercury__private_builtin__'; the MLDS->C back-end 
> 	generates references to these prefixed enumeration constants.
> 	(Doing it this way avoids the need to hard-code representations
> 	of these enumeration constants into the MLDS types.)
> 
> compiler/mlds_to_c.m:
> compiler/ml_unify_gen.m:
> compiler/rtti_to_mlds.m:
> library/exception.m:
> 	Add some casts from `MR_Box' to `Word' or vice versa, so as to
> 	avoid assuming that `MR_Box' is the same type as `Word'.
> 
> compiler/mlds_to_c.m:
> 	Change mlds_output_data_addr so that it handles constants
> 	with array types (specifically some of the RTTI constants),
> 	i.e. don't output `&' for those.
> 
> library/benchmarking.m:
> library/private_builtin.m:
> runtime/mercury.h:
> 	Add some missing #includes.
> 
> library/builtin.m:
> 	Add `#ifndef MR_HIGHLEVEL_CODE' around some code that is
> 	specific to the low-level (LLDS) back-end.
> 



> +:- func rtti_name_has_array_type(rtti_name) = bool.
> +rtti_name_has_array_type(exist_locns(_))		= yes.
> +rtti_name_has_array_type(exist_info(_))			= no.
> +rtti_name_has_array_type(field_names(_))		= yes.
> +rtti_name_has_array_type(field_types(_))		= yes.
> +rtti_name_has_array_type(enum_functor_desc(_))		= no.
> +rtti_name_has_array_type(notag_functor_desc)		= no.
> +rtti_name_has_array_type(du_functor_desc(_))		= no.
> +rtti_name_has_array_type(enum_name_ordered_table)	= yes.
> +rtti_name_has_array_type(enum_value_ordered_table)	= yes.
> +rtti_name_has_array_type(du_name_ordered_table)		= yes.
> +rtti_name_has_array_type(du_stag_ordered_table(_))	= yes.
> +rtti_name_has_array_type(du_ptag_ordered_table)		= yes.
> +rtti_name_has_array_type(type_ctor_info)		= no.
> +rtti_name_has_array_type(pseudo_type_info(_))		= no.
> +rtti_name_has_array_type(type_hashcons_pointer)		= no.

This function belongs closer to the code that generates and defines
these types, otherwise it runs the risk of not being updated correctly.

How about putting it in rtti.m?

If it's too specific to mlds, then rtti_to_mlds might be a better place
for it.  

> @@ -164,11 +178,18 @@
>  		gen_init_type_ctor_rep(CtorRep),
>  		gen_init_maybe_proc_id(SolverProc),
>  		gen_init_maybe_proc_id(InitProc),
> -		gen_init_string(ModuleName),
> +		gen_init_string(TypeModuleName),
>  		gen_init_string(Type),
>  		gen_init_int(Version),
> -		gen_init_functors_info(FunctorsInfo, RttiTypeId),
> -		gen_init_layout_info(LayoutInfo, RttiTypeId),
> +		% In the C back-end, these two "structs" are actually unions.
> +		% We need to use `init_struct' here so that the initializers
> +		% gets inclosed in curly braces.

s/gets inclosed/get enclosed/

(well, s/in/en/ is a matter of taste).

> +/*
> +** XXX Currently we hard-code the declarations of the first
> +** few of these type-info struct types; this imposes a fixed
> +** limit on the arity of types.  Fortunately types with a high
> +** arity tend not to be used very often, so this is probably OK
> +** for now...
> +*/

You should document what the fixed limit it, and what the likely
symptom of the hard-coded limit being breached is (e.g. will it
segfault, or cause an abort, or a compile time error).

> Index: runtime/mercury_type_info.h
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/runtime/mercury_type_info.h,v
> retrieving revision 1.48
> diff -u -d -r1.48 mercury_type_info.h
> --- runtime/mercury_type_info.h	2000/04/16 05:47:21	1.48
> +++ runtime/mercury_type_info.h	2000/04/19 07:09:28
> @@ -363,6 +363,19 @@
>  */
>  
>  /*
> +** For each enumeration constant, we define it using two names;
> +** firstly we define the unqualified name, and then we define
> +** another enumeration constant whose name is the unqualified name
> +** prefixed with `mercury__private_builtin__' and whose value is
> +** the same as that of the unqualified name.
> +** The qualified versions are used by the MLDS->C back-end,
> +** which generates references to them.
> +*/
> +#define MR_DEFINE_ENUM_CONST(x)	\
> +	x,			\
> +	MR_PASTE2(mercury__private_builtin__,x) = x
> +
> +/*

What an evil hack.

As long as it is valid C I guess it's OK.


Other than that the change is ok.


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