Path: utzoo!attcan!uunet!world!esegue!compilers-sender From: mike@thor.acc.stolaf.edu (Mike Haertel) Newsgroups: comp.compilers Subject: Re: compiler generators. Keywords: yacc, lex Message-ID: <1990Oct1.044328.8051@acc.stolaf.edu> Date: 1 Oct 90 04:43:28 GMT References: <90255.105510VMDOS@tecmtyvm.mty.itesm.mx> <1852@tuvie> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: mike@thor.acc.stolaf.edu (Mike Haertel) Organization: St. Olaf College; Northfield, MN Lines: 25 Approved: compilers@esegue.segue.boston.ma.us In article <1852@tuvie> mike@vlsivie.at (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-[23] 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 sure. -- Mike Haertel [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] -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.