From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8149 invoked by alias); 8 Mar 2003 00:19:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8142 invoked from network); 8 Mar 2003 00:19:36 -0000 Received: from unknown (HELO smtp5.wanadoo.nl) (194.134.35.176) by 172.16.49.205 with SMTP; 8 Mar 2003 00:19:36 -0000 Received: from steven.lr-s.tudelft.nl (3eea178f.cable.wanadoo.nl [62.234.23.143]) by smtp5.wanadoo.nl (Postfix) with ESMTP id 683E074653; Sat, 8 Mar 2003 01:19:33 +0100 (CET) Subject: Re: Putting C++ code into gcc front end From: Steven Bosscher To: Neil Booth Cc: Geert bosch , Geoff Keating , per@bothner.com, tromey@redhat.com, gcc@gcc.gnu.org In-Reply-To: <20030307230711.GG31657@daikokuya.co.uk> References: <200303072250.h27MoK706172@desire.geoffk.org> <4CC1276A-50F1-11D7-A6B8-00039344BF4A@gnat.com> <20030307230711.GG31657@daikokuya.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 08 Mar 2003 00:37:00 -0000 Message-Id: <1047082773.732.54.camel@steven> Mime-Version: 1.0 X-SW-Source: 2003-03/txt/msg00554.txt.bz2 Op za 08-03-2003, om 00:07 schreef Neil Booth: > Geert Bosch wrote:- > > > Note that Ada already builds its own tree for a complete > > translation unit. As last action the root of this tree is > > passed to "Gigi", which is the code that converts the GNAT > > trees to GCC trees. However, even though this glue code is > > very local, it is quite complex, and separation still isn't > > quite complete. A better documented back end / front end > > interface would be a great step forward. > > IMO Ada has the best and cleanest GCC front end, despite being I think > the biggest. I wonder if the fact that it has its own representation > is just a coincidence. Well, of course having per-front end IRs gives you better separation between the front end and the middle/back end, and you *may* just get a cleaner front end if you design your new IR carefully.. But having your own representation is in itself not the Holy Grail either. Like Ada, G95 has its own internal representation. The task of translating it to another IR (GENERIC for G95) should not be underestimated. Like Geert said: That code is quite complex indeed. (And I doubt even a million pages of documentation would change that.) What I dislike most is that we go from one internal representation to the next and there is no overlap between them: It's not like WHIRL where you have five (?) different levels, but instead you go from a set of front-end specific parse tree data structs to GENERIC, to GIMPLE, to RTL. These are completely different intermediate representations, only GENERIC->GIMPLE is lowering, and even that step is almost a complete rewrite in some bad cases. Surely you would not want something like that in the C front end. It is funny to see ipf-orc get away with front ends that build their parse tree in their own IRs (most notably the GNU C/C++ front ends that build trees) and then translate that to WHIRL. And we're discussing adding yet another intermediate representation that is nothing like what we have now. Yuck. Greetz Steven