>>>>> "Tim" == Tim Josling <[EMAIL PROTECTED]> writes:
Tim> 1. Sample front-end: Given treelang no longer exists and "is not a good Tim> example anyway" what would be the best front end to use as a model and Tim> to plagiarize code? Tim> What I don't know is how up-to-date the various front ends are and how Tim> good an example they are. I'm not familiar with all the front ends. But, I'd say don't copy gcj (it doesn't do anything very bad AFAIK, but it is also not very well-organized) or the C family (those are the oldest and most tree-enmeshed FEs). When I was writing my front end I just did a lot of grepping through all the FEs to augment what I learned from reading tree.def and tree.h (and cgraph.c and varpool.c and ... bleah). That isn't awesome, but it isn't terrible either. Now I wish I'd taken notes and updated tree.def with the odd things I discovered. GCC would benefit if you did that... Tim> 2. Most-Gimplified front-end: Allied to Q1, which front ends have Tim> been most thoroughly converted to GIMPLE? [...] IMO: don't worry much about gimple, lang hooks, or tuples. Instead, just make trees, following GENERIC. Though, since I don't think GENERIC is extremely well-defined, that means reading tree.def and the like. Going this route will give you one view of procedural code, types, declarations, etc. Tim> 5. What is deprecated: Is there any time-effective way to identify Tim> constructs, header files, macros, variable and functions that are Tim> "deprecated". Like Ian said, things that are truly deprecated tend to be removed. Sometimes this deletion is accompanied by a poisoning in system.h, at least in cases where a merge might potentially do the wrong thing. A couple useful rules of thumb. First, don't add your own tree codes. You won't need them, at least not from what I understand of your overall design. Second, don't add new lang hooks, either. Tom
