| [ptp-dev] Re: [photran] (DEV) Multi-language issues |
On Jun 24, 2005, at 11:21 AM, Jeffrey Overbey wrote:
This is really more appropriate for our developers' list, but I want to leave this open for input from the Photran community, particularly on issue #2.1. First, our code is an ugly copy-and-paste of the CDT, modified to support Photran, and integrating "nicely" with the CDT is a top priority. However, we do not want to be subsumed into the CDT project... rather, the CDT (or CLDT, or whatever generic compiled language tool it becomes) needs to provide extension points so that Photran can remain a separate project with its own release schedule, politics, etc. I am assuming the LANL guys have the same vision... right?
So far I've been just patching CDT (where needed) and adding a few additional interfaces. So far the changes are minor (most of them are making protected methods public, so Fortran can access them outside of the package). We probably should create some extension points once we see how it all works out. I think I'm about finished with the basics (we can look at it detail in July). The primary thing left is to redo the tool chain to fit in with Leo's changes.
The best thing to say about patching CDT is that it only took me 15-20 minutes to upgrade to 3.1-M7. So it is easy to stay current.
I think regular releases of Photran is really a separate topic. I've really been talking about working from CVS HEAD. As I see it, it all can be packaged up as Photran and released on whatever schedule seems appropriate. It might be nice to time them shortly after CDT releases, but I don't think that is essential.
2. Next, integrating with other Fortran tools is inevitable. I think we all realize this. My question is, what might they be? And what sort of program information would they need from Photran?
Are you subscribed to the PTP list? There (and in private emails and phone conversations) we have been discussing with Beth Tibbitts (and others) at IBM about MPI assists and refactorings. I haven't looked at this yet but I assume they walk the C DOM to access MPI calls (same would need to be done for Fortran). We will put this code up on the PTP website as soon as we get permission from IBM.
Other tools are parallel debugging (not sure what is needed here, Greg should inform us) and performance monitoring. The performance tools people we have been working with insert monitoring calls in user code so they need line number information and call and method sites. They are also interested in OpenMP directives so the parser needs to retain comments so directives can be extracted. I have similar ideas about refactorings for CoArray Fortran directives.
Another project I working on (Chasm) needs to extract interface information (procedure names and parameter types).
Integrating a fixed-to-free form converter is on our short list, although this will likely mean "pipe this program through some external executable," unless we decide to write our own. I could see integrating a profiler at some point; this would require some GUI work but would be parse tree-agnostic. Vanderbilt is working on TotalView support (completely independent of Photran). What else?3. Where I'm headed with this is what to do about the program representation. Obviously, this fantastical multi-language CDT should be able to identify the "high level" information in every file. The Projects view should continue to be able to display the modules/subroutines/etc. in each file, for example. So integrating into the CDT's lightweight hierarchy is pretty much going to be a necessity.
Yes, I think so. What I'm really hoping for is (consider extracting a Fortran 2003 BIND(C) interface from a Fortran procedure or a C function) is that the refactoring tool wouldn't have to change much between languages, so at least the high level interfaces for walking the AST will be the same.
As for the heavyweight, refactorable tree that can classify every token in the program, we are not mimicking the CDT's code for this. Theoretically, we could add more classes to the CDT's AST package, essentially making it the union of the AST classes for every language it wants to process. This is what GCC did. And the consensus is that (generally speaking) it is a bad idea. In our specific case, we would have to meddle in the C(L)DT code base more than we would like (see item #1 above). More importantly, what would it gain us? In the language-independent part of the AST, there is no need for such fine-grained information. So the only real way it would be used would be if someone developed some tool that stepped through every source file, regardless of source language, in very fine detail. Such a tool would, of course, have to have knowledge of every feature in every supported language. I can't see this happening. Even for Fortran-only tools, since there is no standard Fortran AST, anything that wants to use Photran's AST is going to have to be rewritten to accommodate its structure, regardless of whether or not it implements the same interface as the CDT DOM. That's the short version of my argument for why we haven't concerned ourselves with imitating the CDT AST.
I think you are probably right about fine details of the AST. However, a colleague and I have been working for a couple of years on static analysis tools (Chasm) to walk C and Fortran ASTs and we have been able to take advantage of the many similarities. I'll list a few of them:
C/C++ Fortran ---------- ------------ namespaces modules functions subroutines and functions structs derived types most primitive types......... I'm attaching the common xml dtd in case you are interested. Cheers, Craig
Attachment:
mapping.dtd
Description: Binary data