Patch: delete treelang

[Tom Tromey]

>>>>> "Tim" == Tim Josling <tejgcc@westnet.com.au> writes:

Tim> Too late now but a few thoughts on this...

It's been bothering me for a couple of days that I didn't address some
of these things in my original note.

I know how hard it can be to have one's code deleted -- I've had to
mourn more than one program that I had worked hard on.  So, I wanted
to thank you for your contribution.

Tim> I suspect that people who have worked on GCC full time for a number of
Tim> years, and who have commit authority, can tend to forget the many
Tim> obstacles that are in front of someone starting work on GCC,
Tim> particularly on a front end.

I've also been through this.  And yes, it is very hard... GCC's
internals have improved greatly in the past years, but there is still
a long way to go.  And, the front end interfaces don't get as much
attention as we might like.

Tim> In particular the front end documentation has traditionally been
Tim> considerably more limited than the documentation for the rest of
Tim> GCC.

Yes.  How can we fix this?

I usually recommend that aspiring front end writers read tree.def (the
most useful source) and skim tree.h (still useful but also a lot of
unreadable goo).

This is not really enough, though.  There are many things that are
undocumented.  And, there is little differentiation inside GCC between
the requirements of different phases of the compiler.

Maybe we could start documenting the tree API in more detail?  I'm a
fan of extracting documentation from the code, a la javadoc.  I feel
that this improves the likelihood that the documentation will actually
be updated when the code is changed.

And, maybe we could simplify the header file situation as
well.. provide a single "front-end.h" or something like that.

Anyway... fixing things here is not a super high priority for me, it
is more like a wish.  And, I've been reluctant to open this topic in
the past.  But maybe a few of us could band together to work on it a
bit.

Tim> As a result, the COBOL compiler will be a separate executable,
Tim> and will pass a binary file to a mini-front end that interfaces
Tim> to the GCC back end.

I wonder whether you've considered writing your front end as a
library.  This preserves the separation of the bulk of your FE from
GCC, but also turns many kinds of divergences into compile-time
errors, and removes a potential source of fragility (i.e, why write
out some binary serialization rather than just C?).

This is the approach I took with gcjx.  I did this primarily because I
did not want to use trees for my IR -- I am not a fan of trees,
really.  Like your FE, gcjx supported multiple back ends.  The gcc
side was the minimal code needed to lower the gcjx IR to trees, plus
the required langhooks and whatnot that all FEs need.

Tom