[G95-develop] G95 AST representation

[POP Sebastian <m1sp at csc dot liv dot ac dot uk>]

> I think it is clear that:
> 
> 1) The current "C" AST is not suitable to deal with languages that do not 
> resemble to the "C" language family.  

I have worked on an AST close to GCC AST : NestorAST. It is created by a 
translation of the AdaptorAST nodes in C++ classes.
But it has the same basis as the GCC AST. There's an online documentation :
http://www.cri.ensmp.fr/~silber/nestor/doc/Adaptorlibrary.html

As you can see it has nodes like do_statements, identifiers, strings, arrays, ...
All these are present in gcc AST. That's why I think it could be possible to 
construct a gcc-like AST from a fortran file. Again, here is *my* point of view. 

> *Maybe* I would agree with you if it  
> was clear how we can "undo" manipulations to the "C" (and friends) AST.   
> Right now I can't find any macro/subroutine to do this.  

I'm not sure about what "undo" means... (again I'm not a fortran specialist.)
But I can help to find a solution :-)

> It should NOT be  
> up to a front end project to add such macros, and direct manipulation of  
> these tree nodes is not an option (GCC policy). 
>
I don't think the gcc project to be so strict on his AST representation...
If the transformed AST can be translated into a correct RTL, all transformations 
are allowed on trees (if they don't produce a negative optimisation).
The transformations are done by replacement of existing nodes by new ones. 
Old nodes are garbage collected after their translation into RTL.

> 2) Even if we would want to create an AST directly from Fortran source code 
> into the structures currently used by GCC, G95 would need *MAJOR* redesign. 
> I don't think that is an option, either.
> 
I will take a look at the G95 sources this weekend. But I have not lot of time,
and I have already a great project. My project can be indefinitely extended, 
and I have finite time :-) . But if I can help, I will do.

> Andy is right.  We should first construct an AST in a G95 native tree, and 
> do name resolution and (at least partial) semantic analysis on this tree.  
> We should not construct a "C" AST until after the parser and the resolution 
> phase are completed.
> 
> But you're right, too:  We should at *some* point create a "C" AST from our 
> own parse tree (as far as I understand, and right I'm not sure I do...). 
> That is just one of the projects we should start working on soon.  I would 
> like to hear from you not the structure of the AST, but what we should do 
> to construct that AST from our current g95_code tree.
> 
I will look at the sources in more details this weekend. 
I have a little idea about what the code is, but I have to really put my hands in 
to be able to speak...

> Just wondering:  Does it make sense to create a "C" AST?  
Yes, the translation to RTL is simpler, since you can reuse the existing 
translation functions. There are also machine independent optimisations on AST.

Again, I'm new to gcc so don't expect to see all the benefits you can take from
the gcc AST representation from me. That are AFAICS the great points.
But other gcc developers can reply to that. 

> What's the 
> benefit of this over creating a "f95tocpp"?  

> If we have to to create a "C" 
> AST for GCC, we might as well opt to convert F95 source to C++ (or jusy 
> plain "C") source, which is probably much easier...
> 



--
POP Sebastian, 
MSc Computer Science
University Louis Pasteur Strasbourg