>>>>> "Dustin" == Dustin Laurence <[EMAIL PROTECTED]> 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
