treelang fix for rs6000 / treelang not proper front end

[Steven Bosscher]

Fergus Henderson wrote:

>On 09-Jun-2003, Steven Bosscher <s.bosscher@student.tudelft.nl> wrote:
>  
>
>>I would also like do discuss the future of treelang.  It is a 
>>neat small front end, but the more I look at it, the less I like it in 
>>its current shape.  IMHO if it is to be an example front end, then it 
>>should set a _good_ example.
>>    
>>
>
>I agree; however, even a merely mediocre example is still a lot better
>than none.
>
I guess so...

>>I had started working on a treelang-like front end that conforms to the 
>>GCC conding style, targets GENERIC and is completely standalone.  It 
>>produces a few non-GENERIC nodes in the parser to show how  lowering the 
>>parse tree to GENERIC would work.  I wanted it to follows 
>>sourcebuild.texi and frontend.texi to the letter.
>>    
>>
>
>That all sounds like a good idea.
>
>  
>
>>I also wanted the parser to build the parse tree using 'tree' and to 
>>build funtions as trees.  I know you probably do not like parsing 
>>directly into 'tree', because treelang now shows how you can _not_ build 
>>trees and still interface with GCC, like most existing front ends (G77, 
>>G95, Ada, COBOL and a few others) actually do.  But using trees from the 
>>start makes the front end much smaller. I used trees because I just 
>>wanted to see how it would look, but I can see why you choose 
>>differently.  It is a matter of what you want to show with treelang.
>>    
>>
>
>My preferance is for a separate parse tree.  Even though this may make
>the source code longer, I still think this is better, because I think
>the separation makes it easier to understand the GCC front-end interface.
>Also this approach scales better to real systems and is the sort of
>approach that we should encourage for new front-ends.
>

Well, should we?  This was Tim's argument for why treelang is as it is 
now.  But one could just as well argue that all front ends should build 
their parse trees using 'tree', with language-specific tree codes where 
needed, and that the fact that so many existing front ends do not do so 
is merely a result of the history of GCC as C/C++ compiler (ie. not a 
compiler collection).  For example, the G77 manual tells about how 
unsuitable 'tree's are for Fortran, but this is no longer true if you're 
doing functions as trees with a genericize pass.

Either way, an example front end to parse to trees still shows how to 
the front end-interface works.  If you look at G95: We walk our own 
parse tree, and piece-by-piece build from it a 'tree' for each 
function.  (We stole the idea from Ada which does something similar, 
only not functions-as-trees.)  This really is not that different from 
parsing a stream of tokens.
The key thing IMHO is that the parser actions (fe_build_thing() 
functions) are properly separated, because that is the only place where 
the 'tree' magic should be happening.  In fact I think it would more 
clearly show how the front-end interface works because most people who 
areinterested in writing a front end to GCC would already know lex/yacc, 
so they can focus on how we build a GCC tree from there.  I don't think 
an example front end should show how to defines a set of datastructures 
for a "native" parse tree, it only complicates things.

>>So, what do we _want_ to show with treelang?  What is the function of 
>>treelang within GCC and what implications does that have for its design?
>>    
>>
>
>The purpose of treelang within GCC, IMHO, is to provide a simple but
>complete and working didactic example of a front-end, in order to make it
>easier for people to understand the front-end interface, and to provide
>something that people writing a new front-end can use as a model on
>which to base their front-ends.
>

I agree with the first part but not necessarily with the last.  IMHO, 
treelang (or an "example front end" in general) should explain the 
front-end interface, period.  It is not supposed to be a 
HOWTO-write-a-GCC-front-end, I think.  (That's more something for an 
O'Reilly book we could write ;-)

Gr.
Steven