[m-dev.] for review: GCC back-end interface

[Tyson Dowd]

On 09-Jan-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 09-Jan-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > On 05-Jan-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:

> > It is interesting to note that many other developers have leaned towards
> > the opposite approach, which is to have a module of simple inline C
> > code in a single Mercury module, and a further module on top of that
> > that handles the more complex parts in Mercury.
> >
> > Are there any technical problems that made such an approach infeasible
> > in this case? 
> 
> Well, actually I've done that, in parts; the further module on top of
> that is mlds_to_gcc.m.  For instance, all the symbol table handling is
> done on the Mercury side, rather than the C side, since it was much
> easier there.
> 
> What I meant by that comment is that any complicated fragments *of C code*
> should go in gcc/mercury/mercury-gcc.c.  I didn't mean that everything
> which is complicated should be done in C rather than in Mercury.

Ok, this is fine division of complexity.  Might be worth mentioning it.

> 
> > Is it the complexity or the "changes for new versions of gcc" that you are
> > concerned about?
> > If so, could you document them here?
> 
> What I'm concerned about is minimizing the size and complexity of the
> Mercury/C interface.  I'm hoping that we can get the C side of the
> changes integrated into the gcc distribution / cvs repository, so that
> when the gcc developers change the interface to the gcc back-end, they
> can fix the Mercury front-end at the same time as they fix all the
> other front-ends.  However, I don't think it is reasonable to expect
> or even to hope that they would do that for Mercury code, or for
> C code which is written as inline `pragma c_code' fragments in Mercury.
> So to minimize the amount of maintenance needed, I want to minimize
> the amount of the GCC back-end interface that the Mercury code depends
> on.

And a bit of this too.  This is a huge piece of C code integration
to have in the compiler so I think it's worth taking some care in documenting
these things.

> > > +% A GCC `tree' representing a function declaration.
> > > +:- type gcc__func_decl.
> > > +
> > > +	% build a function declaration
> > > +:- type func_name == string.
> > > +:- type func_asm_name == string.
> > > +:- pred build_function_decl(func_name, func_asm_name, gcc__type,
> > > +		gcc__param_types, gcc__param_decls, gcc__func_decl,
> > > +		io__state, io__state).
> > > +:- mode build_function_decl(in, in, in, in, in, out, di, uo) is det.
> > > +
> > > +	% Declarations for builtin functions
> > > +:- func alloc_func_decl = gcc__func_decl.	% GC_malloc()
> > > +:- func strcmp_func_decl = gcc__func_decl.	% strcmp()
> > > +:- func hash_string_func_decl = gcc__func_decl.	% MR_hash_string()
> > > +:- func box_float_func_decl = gcc__func_decl.	% MR_box_float()
> > > +:- func setjmp_func_decl = gcc__func_decl.	% __builtin_setjmp()
> > > +:- func longjmp_func_decl = gcc__func_decl.	% __builtin_longjmp()
> > 
> > A few of these seem very Mercury specific.  I understand that this is not
> > supposed to be a *complete* gcc backend interface, but is it supposed to
> > be *completely* a gcc backend interface?
> >
> > Perhaps they would be better in a another module?
> 
> Perhaps.  But there are only three or four such functions
> (GC_malloc, MR_hash_string, MR_box_float, and perhaps strcmp).
> I'm not sure if it is worth creating a new module just for that.

Maybe not -- I made this observation early in the review, and in the end
there turned out to be little to be concerned about.

> 
> This module is supposed to be an interface to the gcc back-end *and*
> to the C side of the Mercury front-end to gcc.  The latter naturally
> includes some parts which are Mercury-specific.  I don't want to split
> it into two parts, one of which interfaces directly to the gcc
> back-end, and the other of which interfaces to mercury-gcc.c, because
> that distinction is not useful to the user of this module.  Many parts
> of mercury-gcc.c are there just to encapsulate the more complicated
> parts of the gcc back-end interface, and at this level I want I want
> to hide the distinction between the native and the encapsulated parts
> of the gcc interface and to just present a single unified interface
> here.
> 
> On the other hand, I could perhaps split gcc/mercury/mercury-gcc.c
> into two files, called say gcc/mercury/encaps.c and gcc/mercury/lang.c,
> one of which does the generic encapsulation, and the other of which
> provides the Mercury-specific stuff.  Then I could define two
> different Mercury modules, one of which (gcc.m) interfaces with
> the gcc back-end and gcc/mercury/encaps.c, while the other
> (gcc_mercury.m?) interfaces with just gcc/mercury/lang.c.
> 
> That might perhaps be worth doing in the long run.
> However, the payoff is pretty small, and its a non-trivial
> amount of work.  For now I think I'll leave it as is and
> just mark it with an XXX comment.

At the moment it seems to be not worthwhile.  If we end up adding more
complex features, this might be worth doing.

> > > +:- pragma c_code(build_initializer_expr(InitList::in, Type::in,
> > > +	Expr::out, _IO0::di, _IO::uo), [will_not_call_mercury],
> > > +"
> > > +	Expr = (MR_Word) build(CONSTRUCTOR, (tree) Type, NULL_TREE,
> > > +		(tree) InitList);
> > > +#if 0
> > > +	/* XXX do we need this? */
> > > +	TREE_STATIC ((tree) Expr) = 1;
> > > +#endif
> > > +").
> > 
> > Please explain.
> 
> Which bit don't you understand?

The XXX part -- it is pretty content-free. 

> The code in #if 0 ... #endif is commented out because I'm not sure if
> it is needed.  
> 
> The TREE_STATIC macro is documented in tree.h in the gcc source code.

Could you add a sentence explaining why we might (or might not) need to
do 
	TREE_STATIC ((tree) Expr) = 1;

Reading the gcc source code tells me that this means allocate static
storage.  But it would be nice to know why you aren't sure whether we
should use it or not -- what are the issues?  Or is it simply something
that needs to be investigated or experimented with and it is more
trouble to document than to investigate?

> > As mentioned in the Mercury meeting, it would be good to factor out this
> > code, and use it to (optionally) generate the appropriate definitions
> > for a header file.  This way we can hopefully avoid the double update
> > problem.
> 
> I discussed this with Zoltan during our meeting with Levi yesterday.
> He managed to convince me that abstracting out these types in a way
> that was language-independent would be difficult, and would require
> inventing a whole new layer of abstraction machinery that might well
> be more complicated to implement and maintain than just living with
> the code duplication.  The basic problem is that many of these
> RTTI types contain variable-sized arrays, unions, function pointers,
> and other complications which would need to be mapped differently for
> different target languages.
> 
> It may be worth doing this, but it is a problem that affects
> all back-ends, and so I think it should be a separate change.

Sure.

> > > +	( { MaybeSize = yes(SizeInBytes0) } ->
> > > +		% Rather than generating a reference to a global variable
> > > +		% mercury__private_builtin__SIZEOF_WORD, we ignore the
> > > +		% word size multiplier, and instead get the word size
> > > +		% from the bytes_per_word option.
> > > +		% XXX This is kludgy.  We should change new_object
> > > +		% so that it has the size in words rather than in bytes.
> > 
> > Yes please!  
> > 
> > If you don't I will.
> 
> I'm happy to do it, but I'll do it as a separate change.

happy(tyson) = happy(larry)

> > I should note that I just skimmed the mercury-gcc.c file.
> > I don't know the gcc backend at all, so I'm going to have to assume it
> > works ;-)
> 
> I plan to get the gcc developers to review that part.
>
> The gcc developers mailing lists are online at gcc.gnu.org.

Cool.  See if they really live up to their mission statement of
supporting more languages ;-)

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