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

[Fergus Henderson]

On 09-Jan-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 09-Jan-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > [Tyson wrote:]
> > > 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.

Yes.  That part of the path is determined by the grade.
But the path can't be completely determined by the grade.

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

? Which strategy was that?

What about the code duplication in the definition of the RTTI _types_
(which is the one that Tyson was objecting too in my diff)?

Are you talking about the strategy in which we provide an abstract
back-end-independent representation of the RTTI types, in a similar way
to the way that we currently provide an abstract back-end-independent
representation of the RTTI values?  I thought that was the strategy
that you persuaded me to reject, based on the grounds that this approach
would be too complex to be worth it.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------