treelang fix for rs6000 / treelang not proper front end

[Tim Josling]

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