This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Front end best practice in GCC 4.1.0?
- From: Tom Tromey <tromey at redhat dot com>
- To: Dustin Laurence <dustin at dogbert dot laurences dot net>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: 29 Mar 2006 15:27:55 -0700
- Subject: Re: Front end best practice in GCC 4.1.0?
- References: <20060329194741.GH2142@alice.wonderland.caltech.edu>
- Reply-to: tromey at redhat dot com
>>>>> "Dustin" == Dustin Laurence <dustin@dogbert.laurences.net> writes:
Dustin> The question is, which front ends are regarded as being good
Dustin> exemplars of style in GCC 4 and which are burdened with legacy
Dustin> code that shouldn't be duplicated in a new project? I gather
Dustin> that at one time the obvious choice, treelang, wasn't all that
Dustin> pretty and the fortran front end was suggested as better, but
Dustin> that was somewhat dated news.
This is kind of vague... what kinds of things do you want to know?
I advocate the overall approach taken by gcjx:
1. Write the front end as a separate library, with its own
representation of the program. In particular, don't use the GCC
tree structure to model the program.
This makes it easier to reuse the front end in other situations.
gcjx has several back ends: java class files, header files (for CNI
and JNI), GCC trees, LLVM was in the works. You could also add
analysis "back ends", etc.
2. Put the front end into its own top-level directory in the source
tree. This removes the temptation to let GCC-isms sneak in.
3. Write a thin layer of glue to convert the front end's internal
representation to GENERIC. Avoid having your own tree codes and
the like (e.g., use build_common_tree_nodes -- don't do like gcj
and roll your own... if you need your own integral types, define
them separately).
In gcjx this glue layer is just one back end among many, and they
are all simply implementations of a code generation interface.
In particular I think the representation choice is critical. The
"old" gcj has had many silly bugs directly traceable to its use of
trees; using a statically typed representation (as in gcjx... the
entire model is C++ classes) eliminates whole classes of bugs.
Oh, yeah, one more thing: write it in C++. GCC's internals are fairly
friendly to C++ these days, and IME it is markedly better than C. At
least, if you try to work at a high level, use the STL, etc.
Tom