This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 'treelang' and GCC function-at-a-time mode
On 12/12/01 08:40 +0200(+0000), Einar Karttunen wrote:
> On 24.12.01 01:42 +0100(+0000), Steven Bosscher wrote:
> > From what I understand so far, the idea of this mode is to use the tree
> > structures that used to be the C AST as a new IR. I should try to make
> > my front-end build a whole tree for each function and translate that
> > tree to RTL, instead of generating and translating trees piece-by-piece
> > (per statement).
> So you are first generating some tree and the converting it to
> gcc internal tree presentation?
Well, yes and no...
Yes, G95 builds a parse tree in a native structure (see g95 docs @
http://home.wanadoo.nl/btp91/g95/g95.html). Andy Vaught had good
reasons for this approach. Anyway, I want to write an interface between
the G95 parser and the GCC back end. This interface should translate
the G95 parse tree to GCC's internal tree presentation.
OTOH no, what I meant is that to use function-at-a-time mode I should
build a whole _GCC ast_ for each Fortran function, instead of generating
a tiny tree for each Fortran statement and translate that tiny tree to
RTL. The latter is how G77, GNU Ada and all other non-C-famoly
front-ends ends work. That's why I don't want to use those as example
front-ends.
I had expected from treelang that it uses function-at-a-time mode, but
I'm quite sure that it does not, which is a pity because it is supposed
to be an example f.e... Maybe I'll try to rewrite treelang, that's a
nice exercise :-)
> http://members.wri.com/johnnyb/compilers/ contains lots of links
> for writing a frontend for gcc. The cobol-documentation is especially
> good, though a bit dated.
I found and studied most of these documents and front ends already, but
thanks anyway :-).
Problem is: none of these f.e.'s use function-at-a-time mode.
AFAIK only GCC's C and C++ front end use it at present. Both use
c-common.c, and like Joseph S. Myers already noted in an earlier reply:
Non-C-family front ends should not use c-common. Obviously Fortran is
not a member of the C-family.
On Thu, 06 Dec 2001, Joseph S. Myers wrote:
> > We will likely have a lot of tree code that can be shared among
> > the different front-ends. Maybe we should start putting common
> > code in tree-* and have C-specific files in c-tree-*?
(See thread "[RFC] Design issues with multiple IRs")
Neil Booth noted that the plan was to wait for another 6 to 12 months
before staring to move stuff to new files (and directories). Is it
really necessary to wait _that_ long?
If I start coding the back-end interface for G95 now, I'll have to
discard large parts and rewrite them to use those generic
macros/functions when they become available. So for me it would be
really nice if generic stuff be moved out of c-common & friends ASAP :-)
Is anybody working on this (especially after the recent merge with the
ast-optimizer branch)?
Greetz
Steven Bosscher