Patch: delete treelang

Tim Josling tejgcc@westnet.com.au
Thu Mar 6 23:20:00 GMT 2008


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

Treelang was based on Richard Kenner's toy language. I packaged it up to
include as a part of GCC because toy had fallen behind the GCC mainline
and no longer worked, and there were various versions floating around
that were all broken in different ways. When I re-started work on my
COBOL compiler again a few months ago, I was very pleased to see
treelang still there because it will make my job of rebuilding an
interface to the GCC back end a lot easier. To that extent it's done its
job for me because it survived almost long enough.

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

The impediments to starting work on GCC, particularly building a front
end, are formidable. Treelang was an attempt to somewhat reduce those
impediments. In particular the front end documentation has traditionally
been considerably more limited than the documentation for the rest of
GCC. The main front ends also tend to fractally mix language-specific
code with the generic GCC back end interface which makes it much harder
to understand what the essentials are and to use one as a starting
point.

Treelang did not entirely solve all these problems but it did provide a
small, simple working model of a compiler front end.

The way I am structuring the COBOL compiler is in part a response to the
difficulties of interfacing to the GCC back end. The interface is poorly
documented, volatile (as shown by the need to patch treelang on a
regular basis), and hard to debug. The way the GCC back end works limits
the ways that the front end can be structured. As a result, the COBOL
compiler will be a separate executable, and will pass a binary file to a
mini-front end that interfaces to the GCC back end. Everything that can
be taken out of the cob1 binary will be. This way I can more easily
employ other code generation strategies such as generating C, generating
Java classes, or using other back ends such as LLVM. This front end will
be a very clean example as it turns out, so all is not lost - there wil
still be a clean front end as an example.

Tim Josling

On Thu, 2008-03-06 at 09:20 -0700, Tom Tromey wrote:
> >>>>> "Jim" == Jim Morrison <phython@google.com> writes:
> 
> Jim> Please go ahead and remove this.  Feel free to move me to write after
> Jim> approval section of the MAINTAINERS file.
> 
> Thanks.  And, thanks for reminding me about MAINTAINERS.
> 
> I am checking in the patch, with the appended addition.
> 
> Tom



More information about the Gcc-patches mailing list