|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)|
|From:||email@example.com (Mike Haertel)|
|Organization:||St. Olaf College; Northfield, MN|
|Date:||Mon, 1 Oct 90 04:43:28 GMT|
In article <1852@tuvie> firstname.lastname@example.org (Inst.f.Techn.Informatik) writes:
>Several approaches are possible. The more conventional is a code generator
>generator which helps in writing (portable) back ends. One such beast is
>the GNU C compiler (gcc). It has been succesfully used for a C++ compiler,
>and front ands for Modula- and Fortran are currently being written.
>But this still requires _you_ to generate the intermediate code (RTL) from
>which gcc works.
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.
The tree representation is largely language-independent. Writing
a new language front end for gcc involves writing a parser and type
checker since the RTL generating pass assumes its input trees are
completely type checked. There may be subtle assumptions made about
the details of the input trees to RTL generation, but I can't say for
Mike Haertel <email@example.com>
[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.
Return to the
Search the comp.compilers archives again.