|compiler generators. VMDOS@TECMTYVM.MTY.ITESM.MX (Ing. Pablo Tejeda Zeron) (1990-09-12)|
|Re: compiler generators. firstname.lastname@example.org (1990-09-25)|
|Re: compiler generators. email@example.com (1990-10-01)|
|Re: compiler generators. firstname.lastname@example.org (1990-10-03)|
|Re: compiler generators. email@example.com (1990-10-03)|
|Re: compiler generators. firstname.lastname@example.org (1990-10-04)|
|Summary:||New front ends for gcc|
|Organization:||Technical University of Vienna, AUSTRIA|
|References:||<90255.105510VMDOS@tecmtyvm.mty.itesm.mx> <1852@tuvie> <1990Oct1.email@example.com>|
|Date:||3 Oct 90 11:45:46 GMT|
In article <1990Oct1.firstname.lastname@example.org>, email@example.com (Mike Haertel) writes:
> I beg to differ, but the bulk of the RTL generating pass of gcc is
> language-independent and takes a tree representation as its input.
Yes, this is what I remember also. But this leaves you with having to
generate the tree. As you you have pointed out, you have to
type-check the tree, also there are things like writing symbol tables and all
this really _boring_ stuff. The truth is, you don't have to generate RTL,
but a tree representation which can then be translated to RTL.
> [My impression is that the tree routines would need some work for languages
> that aren't semantically very similar to C, but I haven't looked very hard.
Just what my impression is. In fact, there are hacks made by Michael
Tiemann to support C++. But maybe we can get some information from
somebody who is _writing_ a new front end?
It also seems to be necessary to hack some parts of gcc proper to
accomodate statically nested procedures and other things unknown in
Michael K. Gschwind, Institute for VLSI-Design, Technical University, Vienna
Voice: (++43).1.58801 8144
Return to the
Search the comp.compilers archives again.