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

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

Steven Bosscher wrote:
>>
>> I agree; however, even a merely mediocre example is still a lot better
>> than none.
>>
> I guess so...
>

If treelang is removed, we would be back to where we were, multiple 
non-working far worse examples.

>>
>> 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.
>

Personally I like to build my own language specific parse tree and then 
rtl-ize it in a separate module. I did this with my cobol compiler. I 
felt that with treelang this just complicates things because it is not 
core to the back end interface, but I don't mind either way for 
treelang. I totally agree that the back end interface should be in a 
seperate module as far as possible. This (keeping all back end 
interfaces in one module) is not currently possible though.

Maybe we should put in a comment, saying what the recommended approach is?

This raises a separate issue which I will write another email about. At 
work I am a software architect. We have a set of principles that 
developers need to use, within reason, for buiding systems. But GCC 
development really doesn't have that in any explicit form. For example, 
I think all front end specific stuff should be in front end specific 
directories do f/e developers do not have to hack the main compiler. But 
when someone added a whole lot of front end specific stuff to 
gengtype.c, there was no written down principle you could appeal to to 
say you shouldn't do that.

>>> 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


It certainly should make it easier to write a front end. However to be 
useful it need not be perfect. Actually the word 'easy' does not really 
apply to writing a front end, 'less onerous' would be more accurate.

I'm not sure the size of audience is there for a book. But I would buy a 
copy for sure.

Tim Josling