[m-dev.] for review: centralizing variable names in the debugger

Mark Anthony BROWN dougl at cs.mu.OZ.AU
Thu Sep 21 18:34:22 AEDT 2000


Zoltan Somogyi writes:
> For review by Mark.
> 
> Store the offsets leading to the names of variables in a central location.
> Previously, each label layout included offsets for the variables live at that
> label; now we store the offsets of variables in the proc layout. The new
> data structure will soon be required by the declarative debugger for
> displaying contours through representations of HLDS goals.
> 
> compiler/code_gen.m:
> 	Preserve the varset of every procedure for use by stack_layout.m.
> 
> compiler/continuation_info.m:
> 	Add a field to the cell from which proc layouts are derived to hold
> 	the varset.
> 
> compiler/stack_layout.m:
> 	Delete the offsets from label layouts and add them to proc layouts.
> 	The var name offsets array will always contain meaningful offsets
> 	for every variable that is live at a label with a label layout; with
> 	--trace-decl, it will also contain meaningful offsets for all the
> 	other variables in the procedure body.
> 
> runtime/mercury_stack_layout.h:
> 	Reflect the change in the types of the label and proc layout
> 	structures.
> 
> trace/mercury_trace.c:
> trace/mercury_trace_vars.c:
> 	Look up variable names using the new location of the offsets leading to
> 	them.
> 
> Zoltan.
> 

This change is fine.  I have just a few comments:


> Index: compiler/stack_layout.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/stack_layout.m,v
> retrieving revision 1.49
> diff -u -r1.49 stack_layout.m
> --- compiler/stack_layout.m	2000/09/04 22:33:50	1.49
> +++ compiler/stack_layout.m	2000/09/11 03:33:41

> @@ -1121,17 +1192,17 @@
>  			rval,	% Rval describing the type of a live value.
>  			llds_type, % The llds type of the rval describing the
>  				% type.
> -			rval,	% Rval describing the variable number of a
> -				% live value. Always of llds uint_least16.
> +			rval	% Rval describing the variable number of a
> +				% live value. Always of llds type uint_least16.
>  				% Contains zero if the live value is not
>  				% a variable. Contains the hightest possible
>  				% uint_least16 value if the variable number
>  				% does not fit in 16 bits.
> -			rval	% Rval describing the variable name of a
> -				% live value. Always of llds uint_least16.
> -				% Contains zero if the live value is not
> -				% a variable, or if it is a variable with
> -				% no name.
> +	%		rval	% Rval describing the variable name of a
> +	%			% live value. Always of llds type uint_least16.
> +	%			% Contains zero if the live value is not
> +	%			% a variable, or if it is a variable with
> +	%			% no name.
>  		).

Why not remove this field entirely?

>  
>  	% Construct a vector of (locn, live_value_type) pairs,
> @@ -1142,7 +1213,7 @@
>  	stack_layout_info::in, stack_layout_info::out) is det.
>  
>  stack_layout__construct_liveval_arrays(VarInfos, LengthRval,
> -		TypeLocnVector, NameVector) -->
> +		TypeLocnVector, NumVector) -->
>  	{ int__pow(2, stack_layout__short_count_bits, BytesLimit) },
>  	stack_layout__construct_liveval_array_infos(VarInfos,
>  		0, BytesLimit, IntArrayInfo, ByteArrayInfo),
> @@ -1156,21 +1227,21 @@
>  	{ LengthRval = const(int_const(EncodedLength)) },
>  
>  	{ SelectLocns = lambda([ArrayInfo::in, MaybeLocnRval::out] is det, (
> -		ArrayInfo = live_array_info(LocnRval, _, _, _, _),
> +		ArrayInfo = live_array_info(LocnRval, _, _, _),
>  		MaybeLocnRval = yes(LocnRval)
>  	)) },
>  	{ SelectTypes = lambda([ArrayInfo::in, MaybeTypeRval::out] is det, (
> -		ArrayInfo = live_array_info(_, TypeRval, _, _, _),
> +		ArrayInfo = live_array_info(_, TypeRval, _, _),
>  		MaybeTypeRval = yes(TypeRval)
>  	)) },
>  	{ SelectTypeTypes = lambda([ArrayInfo::in, CountTypeType::out] is det,(
> -		ArrayInfo = live_array_info(_, _, TypeType, _, _),
> +		ArrayInfo = live_array_info(_, _, TypeType, _),
>  		CountTypeType = 1 - yes(TypeType)
>  	)) },
> -	{ AddRevNumsNames = lambda([ArrayInfo::in, NumNameRvals0::in,
> -			NumNameRvals::out] is det, (
> -		ArrayInfo = live_array_info(_, _, _, NumRval, NameRval),
> -		NumNameRvals = [yes(NameRval), yes(NumRval) | NumNameRvals0]
> +	{ AddRevNums = lambda([ArrayInfo::in, NumRvals0::in,
> +			NumRvals::out] is det, (
> +		ArrayInfo = live_array_info(_, _, _, NumRval),
> +		NumRvals = [yes(NumRval) | NumRvals0]
>  	)) },

Is there still a reason to stick to the old syntax for lambda expressions?


> Index: runtime/mercury_stack_layout.h
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/runtime/mercury_stack_layout.h,v
> retrieving revision 1.37
> diff -u -r1.37 mercury_stack_layout.h
> --- runtime/mercury_stack_layout.h	2000/08/03 06:18:54	1.37
> +++ runtime/mercury_stack_layout.h	2000/09/11 03:41:53
> @@ -248,8 +248,8 @@
>  ** The last three fields are meaningful only if the MR_has_valid_var_count
>  ** macro returns true.
>  **
> -** The names array pointer may be NULL, in which case no information about
> -** variable names is available.
> +** The var nums array pointer may be NULL, in which case no information about
> +** variable numbers is available.
>  **
>  ** The type parameters array may also be NULL, but this means that there are
>  ** no type parameters in the types of the variables live at this point.
> @@ -258,9 +258,9 @@
>  */
>  
>  typedef	struct MR_Stack_Layout_Vars_Struct {
> -	MR_Integer			MR_slvs_var_count;
> +	MR_Integer		MR_slvs_var_count;
>  	void			*MR_slvs_locns_types;
> -	MR_Var_Name		*MR_slvs_names;
> +	MR_uint_least16_t	*MR_slvs_var_nums;
>  	MR_Type_Param_Locns	*MR_slvs_tvars;
>  } MR_Stack_Layout_Vars;
>  

I think there are no other places where MR_Var_Name is used, so you could
delete its definition from this file.

Cheers,
Mark.

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