[m-dev.] for review: --target option, IL grades and copy-in/copy-out for MLDS

[Tyson Dowd]

On 05-Sep-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> >  
> > +	% return `yes' iff this module defines the main/2 entry point.
> > +:- func mercury_compile__mlds_has_main(mlds) = bool.
> > +mercury_compile__mlds_has_main(MLDS) =
> > +	(
> > +		MLDS = mlds(_, _, _, Defns),
> > +		list__member(Defn, Defns),
> > +		Defn = mlds__defn(Name, _, _, _),
> > +		Name = function(FuncName, _, _, _), 
> > +		FuncName = pred(predicate, _, "main", 2)
> > +	->
> > +		yes
> > +	;
> > +		no
> > +	).
> > +
> 
> That bit should probably be committed separately, with the IL stuff that
> uses it, since as far as I can tell, in this diff that function is not used.

Yes, I'll remove that bit.

> 
> > +++ compiler/ml_call_gen.m	2000/09/04 00:41:56
> > @@ -83,6 +83,12 @@
> >  :- mode ml_gen_box_or_unbox_lval(in, in, in, in, in, out, out, out, out,
> >  		in, out) is det.
> >  
> > +	% XXX document this
> > +:- pred ml_gen_cont_params(list(mlds__type), mlds__func_params,
> > +		ml_gen_info, ml_gen_info).
> > +:- mode ml_gen_cont_params(in, out, in, out) is det.
> 
> The comment there needs fixing; I suggest the following:
> 
> 	% Generate the appropriate MLDS type for a continuation function
> 	% for a nondet procedure whose output arguments have the
> 	% specified types.
> 
> > Index: compiler/ml_code_gen.m
> ...
> > @@ -1717,8 +1871,19 @@
> >  			raw_target_code("\t\tif (MR_succeeded) {\n")],
> >  			AssignOutputsList
> >  	]) },
> > +	=(MLDSGenInfo),
> > +	{ ml_gen_info_get_module_info(MLDSGenInfo, ModuleInfo) },
> > +	{ module_info_globals(ModuleInfo, Globals) },
> > +	{ globals__lookup_string_option(Globals, target, Target) },
> >  	( { CodeModel = model_non } ->
> > -		ml_gen_call_current_success_cont(Context, CallCont)
> > +		(
> > +			{ Target = "il" }
> > +		->
> > +			ml_gen_call_current_success_cont_indirectly(Context,
> > +				CallCont)
> > +		;
> > +			ml_gen_call_current_success_cont(Context, CallCont)
> > +		)
> 
> I don't understand that if-then-else.
> 
> I also don't recall writing that one.  Ah, looking at the log messages
> in the p7 repository I see that that code was added later, by Tyson.
> 
> A comment here would help a lot.
> What's the difference between calling the continuation directly
> and indirectly?  And Why does it have to be done different for IL?

You figured it out below.  I missed this part of the diff, I'll remove
this and re-post the diff.

> 
> > Index: compiler/ml_code_util.m
> > @@ -326,9 +337,11 @@
> >  	% of local variables in the containing procedure) for the continuation
> >  	% function.  (If we're using gcc nested function, the `cont_env'
> >  	% is not used.)
> > +	% XXX need to update this documentation
> >  	%
> > -:- pred ml_initial_cont(success_cont, ml_gen_info, ml_gen_info).
> > -:- mode ml_initial_cont(out, in, out) is det.
> > +:- pred ml_initial_cont(list(mlds__lval), list(prog_type), success_cont,
> > +			ml_gen_info, ml_gen_info).
> > +:- mode ml_initial_cont(in, in, out, in, out) is det.
> 
> That XXX should be fixed.
> The comment should explain the role of the two new parameters.
> 
> > +	% Generate code to call the current success continuation, using
> > +	% a local function as a proxy.
> > +	% This is used for generating success when in a model_non context
> > +	% from within pragma C code (currently only in IL).
> > +	%
> > +:- pred ml_gen_call_current_success_cont_indirectly(prog_context, 
> > +		mlds__statement, ml_gen_info, ml_gen_info).
> > +:- mode ml_gen_call_current_success_cont_indirectly(in, out, in, out) is det.
> 
> That documentation doesn't explain why we need to use a local function
> as a proxy when in calling something in a model_non context from
> within pragma C code in IL.
> 
> Ah, it's all coming back to me now...
> MS Managed C++ won't let you call via a function pointer, and
> with `--target il' we generate managed C++ for `pragma c_code' fragments,
> which we put in a different file, so if we want to make a call to
> a continuation, we need to put the call in a separate function
> so that it gets compiled as C rather than managed C++.
> But this should all be documented.

Yes, but better to do this in a separate diff.

I'll address your comments and post a revised diff.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------