[m-dev.] diff: Compiler support for stack_layouts

[Tyson Dowd]

On 09-Dec-1997, Fergus Henderson <fjh at cs.mu.oz.au> wrote:
> On 27-Oct-1997, Tyson Richard DOWD <trd at cs.mu.oz.au> wrote:
>    ^^^^^^^^^^^

Aren't mutt generated attribution dates nice...

> 
> > This diff is the compiler support for stack layouts. 
> 
> This has been lying around in my "in tray" for a while...
> long enough, in fact, that I can't even recall whether or not I've
> already reviewed it.  But anyway, here goes...

No, but Zoltan did.

> 
> > -	% Pseudo-typeinfos are just like typeinfos, but can also
> > -	% store type variables. We store type variables as integers,
> > -	% which will always have low values.
> 
> These comments are useful, I think, and so perhaps they should be moved
> somewhere appropriate rather than deleted?

This is a less complete duplicate of comments that are at the top of
the file. It was helpful, but it's more helpful to read the full
definition of a pseudo-type-info.

> >  :- module continuation_info.
> >  
> >  :- interface.
> >  
> > -:- import_module list, llds.
> > +:- import_module list, llds, hlds_pred.
> 
> Please keep the lists of library modules and compiler modules separate.

Done.

> >  	( 
> >  		{ GC = accurate }, 
> > -		set_string_opt(gc, "accurate") 
> > +		set_string_opt(gc, "accurate"), 
> > +		set_bool_opt(stack_layout, yes) 
> 
> Please add a comment "`--gc accurate' implies `--stack-layout'"
> or "we need stack layouts for accurate gc" or something like that.
> 

Done.

> > diff -u -r1.211 llds.m
> > --- llds.m	1997/10/12 13:32:31	1.211
> > +++ llds.m	1997/10/21 01:54:18
> > @@ -75,6 +75,7 @@
> >  			string,			% predicate name
> >  			int,			% arity
> >  			llds_proc_id,		% mode number
> > +			pred_proc_id,		% the pred_proc_id this code
> >  			list(instruction)	% the code for this procedure
> 
> I don't understand -- why do you have both the pred_proc_id
> and also the llds_proc_id?  Doesn't the pred_proc_id include the
> llds_proc_id?

You're quite right. This change was easier, but it would be better to
fix this. I'll work on it now.

> 
> options.m:
> > +	io__write_string("\t--stack-layout\n"),
> > +	io__write_string("\t(This option is not for general use.)\n"),
> > +	io__write_string("\t\tGenerate stack_layout structures.\n"),
> 
> Did you document this in user_guide.texi?

No. This is for "development" use only at the moment.

> 
> Is this option actually useful -- that is, would it ever make
> sense to enable stack layouts when not doing accurate gc,
> or to enable accurate gc but disable stack layouts?
> If not, it would be better to not document it; the option
> can remain, but you should document in options.m that it is
> for internal use only and delete the entry for it from the
> `long_options' list so that it can't be used.
>

Glad you asked, I wanted some feedback on this idea.

This option is temporary -- in future I think we'll have a
"basic_stack_layout" option, that will be used to provide stack traces
on errors, and might be switched on by default.  

Then there will be a "tracing_stack_layout" which will fill in some more
fields of the stack layout with information about the headvars (for
tracing). 

And finally, a "agc_stack_layout" which will fill in different fields
of the stack layout with information about live variables at
continuations (for accurate gc).

Probably all of these will be "invisible" options, as you suggest 
"stack_layout" should be at the moment, turned on by other options
such as tracing, or accurate gc.

I'd prefer to leave it switchable for the moment, but I've documented
a summary of what I've said in the above paragraph in options.m so that
nobody gets too attached to this option.


The other comments you made had already been fixed after Zoltan's
review. I'll send a new diff of these changes in a little while.

-- 
       Tyson Dowd           # 
                            #         Linux versus Windows is a 
     trd at cs.mu.oz.au        #            Win lose situation.
http://www.cs.mu.oz.au/~trd #