[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[photran-dev] What's going on with Photran
|
FYI - I sent this to Craig for a talk he's giving...
Hi Craig,
Here's what's going on with Photran. It's not polished or anything, but
it should give you a few things to talk about. I copied Ralph and our
undergrads in case they have comments/corrections and photran-dev in
case anyone else is listening. Sorry for the length; pick out the
interesting tidbits.
Recently, our work has been proceeding along two fronts: the debugger
and the refactoring/analysis engine.
For their Senior Project, three of our undergrads teleconferenced with
Walt Brainerd to discuss some of the issues that have been brought up
repeatedly on the mailing list about using the CDT debugger/gdb with
Fortran and g95 in particular. Then they proceeded to clone the CDT
debugger and fix a few of the problems. Among them, g95 produces a
number of superfluous variables in the Variables view (their names all
begin with "u" or "sc"), which are now hidden; Conditional Breakpoints
had to be set using C/C++ syntax but can now be set with Fortran syntax;
and, when it can be statically determined from the source code, arrays
display in the Variables and Expressions views with the correct lower
and upper bounds. The new Photran Debugger provides "Run As > Local
Fortran Application" and "Debug As > Local Fortran Application" in the
launch menus.
There is lots of future work that could be done with the debugger.
Multidimensional arrays still don't display correctly, which someone
complains about every few weeks on the mailing list. Also, the current
Photran Debugger is a hacked clone of the CDT debugger, and while
upstream-ing the changes to CDT sounds ideal, some of the changes were
made were fairly "deep" in the debugger (e.g., one was made to CValue, a
class which I believe represents the value of a variable when it is
returned from MI), so properly making the CDT debugger more flexible
would be a nontrivial design task. Nevertheless, the current set of
changes is very useful per se, and the Photran Debugger will be released
this summer with the next release of Photran. There are no plans to add
additional features to the debugger at the moment, although it will
remain on our list of possibilities for undergrad projects.
On another front, we are finally about to make good on our years-old
promise that we will have refactoring support for Fortran. We demoed
the primitive beginnings of our refactoring support at the PTP BOF at
EclipseCon '06, but a lot has been done since then. (Unfortunately, it
looks the same in the GUI... except the results are actually correct and
there are fewer error messages.) We have an actual (machine-generated,
rewritable) AST and support for re-indenting code to match its
surroundings when it is moved in the AST. We finally have reliable
binding analysis/symbol table support, including implicit variables and
bindings of symbols imported from modules in other files (which means we
also have module paths). This means we can find the declaration of a
symbol, look up variable types and array bounds, intents, implicit
status, etc. INCLUDE lines are also handled, so symbols can be declared
in one file and that file included in another. I have also started on a
type checker, which is essential for resolving bindings of derived type
components, although it may be a couple of months before that is useful,
due partly to Fortran's insane number of intrinsic procedures. In the
fall, another grad student created a Fortran indexer, which caches all
of the information Photran needs to refactor across files: what files
INCLUDE what other files, what files import what modules, what files
export what modules, etc.
The net result is that we have one new UI feature (Open Declaration
[F3]) and at least two new refactorings: Rename and Introduce Implicit
None. We may have a couple of other refactorings as well -- for
example, Canonicalize Capitalization (capitalize all of the occurrences
of a variable consistently with the capitalization in its declaration --
essentially a variation on Rename) or Extract Local Variable -- it
depends on how much I can get done over the next couple of weeks. There
are several issues (e.g., common blocks and interfaces) that are still
not handled correctly in the symbol tables/binding analysis, so that
will take priority. The first refactorings will be released this summer.
It's impossible to make a definitive statement of what will happen in
the future with Photran: it depends on funding, the number of other
students involved, my dissertation committee, etc.
We want to put together a group of students to integrate Bill Pugh's
Omega Library to do dependence analysis, and then implement some of the
well-known parallelization techniques (for OpenMP) as refactorings.
These would include things like loop interchange, loop alignment, loop
distribution and fusion, scalar expansion, loop skewing, and loop
unrolling. Oddly enough, essentially this same thing was done 10-15
years ago, and basically every project that did it failed (!), so, in
some way or another, we need to find out why. I don't know at the
moment whether a modern UI (Eclipse) and the "buzz" about refactoring is
enough to make this attempt successful, or if there are some more
fundamental problems.
I have several dissertation-related projects that integrate directly
with Photran.
As part of my master's thesis, I developed a new parsing algorithm
(LAGPLR) which is similar to LALR but allows for unbounded lookahead.
This should make developing machine-generated parsers for languages like
Fortran and C++ significantly easier. Unfortunately, the algorithm is
entirely theoretical at the moment; I plan to implement a LAGPLR parser
generator to get some empirical results.
Photran's rewritable AST is automatically generated by my parser
generator. Under the hood, it is a bit complicated, but essentially,
for any grammar you give it, it will create a rewritable AST. This
means that if you have a LALR grammar for C, Java, HTML, or any other
language, you can have a rewritable AST "for free." So the only thing
you have to add to have a refactoring engine is re-indentation code
(easy) and analysis support -- symbol tables, data flow analysis,
dependence analysis, or whatever you need for the refactorings you want
to create. I plan to create at least two more refactoring engines --
perhaps one for parsing grammars and one for C -- as a proof of concept.
I also want to look into some of the work that has been done on
automatically generating symbol tables, data flow analyzers, etc. to see
if the process of creating a refactoring engine can be simplified further.
C preprocessor directives severely complicate refactoring. One of my
former colleagues (Alejandra Garrido) did her entire dissertation on
this subject in the context of the C language. I have a few ideas of
how to simplify the process slightly, and to support C preprocessor
directives in any language, not just C. Time permitting, I would also
like to have full support for refactoring C-preprocessed Fortran as a
proof-of-concept.
Longer term, we will be looking more at refactorings for parallelization
and refactorings specific to Fortran. There are lots of possibilities
for modernizing old Fortran code. Previous work on parallelization has
essentially looked at the problem from the standpoint of a compiler, and
we believe some refactorings can be discovered by looking at the problem
from a higher level (are there refactorings common to, say, FFT
applications, or sparse linear algebra applications?) or from a design
perspective (how can Eclipse and a refactoring engine help to maintain
the readability and the design integrity of a parallelized
application?). There is certainly more to say about this, but the
things I mentioned above are enough to keep me occupied for quite some
time and are probably of the most immediate interest to your audience.
Hope this was useful.
Jeff
