This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Front end best practice in GCC 4.1.0?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]