Re: treelang fix for rs6000 / treelang not proper front end

[Tim Josling <tej at melbpc dot org dot au>]

Steven Bosscher wrote:

> However, 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.  Actually I had already sort of given up on 
> treelang.
>
> 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.
> (Unfortunately most if it got lost when my computer went up in flames...)
>
> 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.
>
> 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?
>
> Gr.
> Steven

The purpose is to make it easier for people to write front ends.

If building trees is the best way to write front ends, it should do that.

I don't fully understand what you are saying, but I think there are two 
questions.

1. Should you build trees which are then converted into rtl a function 
at a time. I think the answer here is you should use function at a time 
- i.e. build trees, not, go directly to rtl as treelang does now. 
However I have no experience with FAAT so I am really taking your word 
for it.

2. Should the front end have its own language-specific tree 
representation which is then later converted into gcc-specific things 
(eg trees or rtl)?

This depends on the context. For example, one may want to generate C out 
of the compiler, sometimes, instead of front ending GCC back end. In 
this case, you really need your own representation. Having your own 
representation also increases the isolation of the front end from the 
innards of GCC. With the COBOL compiler I have found this to be a very 
good thing.

Tim Josling