From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?) From: forsyth@vitanuova.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-udzpwtqfhvytlxgkgihaxqahbc" Message-Id: <20011109134911.77E5019A41@mail.cse.psu.edu> Date: Fri, 9 Nov 2001 13:54:54 +0000 Topicbox-Message-UUID: 1c7572b0-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-udzpwtqfhvytlxgkgihaxqahbc Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit sorry, i wasn't clear. i meant that you'd need to change the gnat code generator to generate a different representation, not that you'd need another code generator working from the RTL. as you say, gcc's RTL is machine-specific. by `if gnat is structured so as to allow another ... in principle', i meant, it has some internal representation of the Ada program that is at or near a useful level for code generation, before it produces RTL. if it is producing RTL directly from a basic parse tree, you'll have your work cut out. i don't remember dewar's description of gnat's structure, except that it converts its internal representation of Ada to RTL at some point, so i don't know the answer and i can't be much more specific without looking at Gnat's code (which i've also seen but forgotten as regards this point). it was a good five years ago and i was curious rather than interested. --upas-udzpwtqfhvytlxgkgihaxqahbc Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-2.mail.demon.net by mailstore for forsyth@vitanuova.com id 1005303572:20:04317:13; Fri, 09 Nov 2001 10:59:32 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-2.mail.demon.net id aa2004344; 9 Nov 2001 10:59 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 3FB5B19A28; Fri, 9 Nov 2001 05:57:41 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from mercury.bath.ac.uk (mercury.bath.ac.uk [138.38.32.81]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 93180199BB for <9fans@cse.psu.edu>; Fri, 9 Nov 2001 05:56:51 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 16292Y-0004PI-00 for 9fans@cse.psu.edu; Fri, 09 Nov 2001 10:37:38 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu Message-ID: <874ro5vz8b.fsf@becket.becket.net> Organization: University of California, Irvine Content-Type: text/plain; charset=us-ascii References: <20011108150338.12AC919A35@mail.cse.psu.edu> Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?) Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Fri, 9 Nov 2001 10:17:07 GMT forsyth@vitanuova.com writes: > the gnat code generator doesn't generate code > directly (or it didn't), it generates the gcc internal representation, > so it's a non-trivial modification, even if gnat is structured > so as to allow another code generator in principle. The "gcc internal representation" (RTL) is not something a different code generator could work with. The definition of "valid RTL" is entirely machine-specific and so forth. When a GCC front-end begins writing RTL, it is tightly coupled with the back-end. (Indeed, it generates RTL mostly by asking the back-end to spit out RTL for various operations.) The value of RTL in GCC is not to firmly decouple the front end from the back end, but rather to decouple optimizations from the back end. Thomas --upas-udzpwtqfhvytlxgkgihaxqahbc--