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

[Zoltan Somogyi]

On 09-Jan-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > >  :- type compilation_target
> > > -	--->	c	% Generate C code
> > > +	--->	c	% Generate C code (including GNU C)
> > >  	;	il	% Generate IL assembler code
> > >  			% IL is the Microsoft .NET Intermediate Language
> > > -	;	java.	% Generate Java
> > > +	;	java	% Generate Java
> > >  			% (this target is not yet implemented)
> > > +	;	asm. 	% Compile directly to assembler via the GCC back-end.
> > > +			% Do not go via C, instead generate GCC's internal
> > > +			% `tree' data structure.
> > > +			% (Work in progress.)
> > 
> > While the comment about going via the GCC backend is correct, it's
> > pretty irrelevant to the compilation_target.
> 
> I don't agree; it is relevant, because the compiler assumes that the
> compilation_target determines the path taken.  The option to
> select compilation via the GCC back-end is `--target asm'.

This would suggest that the --target option and the compilation_target type
are both misnamed. However, compilation_target does not specify the path taken
if the target is C, since it doesn't say whether the C code should be 
generated via LLDS or MLDS.

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

Just to bring everyone else up to date: The reason I could persuade Fergus
to accept code duplication is because we did identify a strategy where the
code duplication required would be confined almost entirely to the code
which writes out the RTTI data in the syntax required by a given backend,
which tends to be fairly trivial code that is also easy to test. The complex
code required to generate the RTTI data in the first place will be shared
between backends to the extent allowed by their semantic limitations.
The introduction of layout.m and layout_out.m is part of this strategy.

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