Path: utzoo!attcan!uunet!snorkelwacker!mintaka!spdcc!esegue!compilers-sender
From: mike@vlsivie.at (Inst.f.Techn.Informatik)
Newsgroups: comp.compilers
Subject: Re: compiler generators.
Summary: New front ends for gcc
Keywords: yacc, lex
Message-ID: <1898@tuvie>
Date: 3 Oct 90 11:45:46 GMT
References: <90255.105510VMDOS@tecmtyvm.mty.itesm.mx> <1852@tuvie> <1990Oct1.044328.8051@acc.stolaf.edu>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: mike@vlsivie.at (Inst.f.Techn.Informatik)
Organization: Technical University of Vienna, AUSTRIA
Lines: 30
Approved: compilers@esegue.segue.boston.ma.us

In article <1990Oct1.044328.8051@acc.stolaf.edu>, mike@thor.acc.stolaf.edu (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.
>  -John]

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 
C/C++.

Michael K. Gschwind, Institute for VLSI-Design, Technical University, Vienna
mike@vlsivie.at
mike@vlsivie.uucp
e182202@awituw01.bitnet
Voice: (++43).1.58801 8144
Fax:   (++43).1.569697
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.