From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2fae03f0f748c1990adba569cacc92c4@coraid.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] new compilers From: Brantley Coile Date: Sat, 25 Mar 2006 16:33:19 -0500 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-pplwizlhztzmhqkbfehdmhnfvc" Topicbox-Message-UUID: 2126e0bc-ead1-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-pplwizlhztzmhqkbfehdmhnfvc Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit {I remember Boyd.} #ifdef's are only for commenting out code. Kenc is finished compiling while gcc is still paging in. The syntax tree in kenc is the intermediate representation. The man page for GCC is 1.5 times larger than the 8c source. RTL is just a way to make C into lisp. {I miss him.} --upas-pplwizlhztzmhqkbfehdmhnfvc Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by coraid.com; Sat Mar 25 15:39:38 EST 2006 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id D880412C07 for ; Sat, 25 Mar 2006 15:39:37 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id DB0C812BF5 for <9fans@cse.psu.edu>; Sat, 25 Mar 2006 15:39:22 -0500 (EST) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01637-01-3 for <9fans@cse.psu.edu>; Sat, 25 Mar 2006 15:39:22 -0500 (EST) Received: from dexter-peak.quanstro.net (dialup-4.252.203.15.Dial1.Chicago1.Level3.net [4.252.203.15]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 25BBD12BEC for <9fans@cse.psu.edu>; Sat, 25 Mar 2006 15:39:21 -0500 (EST) Received: from bemidji.quanstro.net (unknown [192.168.0.146]) by dexter-peak.quanstro.net (Postfix) with ESMTP id 36D94125B7E for <9fans@cse.psu.edu>; Sat, 25 Mar 2006 14:38:26 -0600 (CST) Message-ID: Date: Sat, 25 Mar 2006 15:28:35 -0600 From: quanstro@quanstro.net To: 9fans@cse.psu.edu Subject: Re: [9fans] new compilers In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+brantley=coraid.com@cse.psu.edu Errors-To: 9fans-bounces+brantley=coraid.com@cse.psu.edu On Sat Mar 25 14:06:26 CST 2006, forsyth@terzarima.net wrote: > > no no no... when you change code you're supposed to add more code. > > Aren't you paying attention to the way software development apparently > > works? :) > > in some ways, the code reduction result is closer to the general approach > encouraged by earlier pioneers in the field. it's one reason there was once > a little dismay of the choice of `lines of code produced' as a productivity metric. > these days, it sells code generators. not the sort that russ changed that does some real work, > but the sort that generates thousands of lines of asn.1 parser that people then tweak by hand. > but i digress... > > ken's compilers used a `copy and change' method rather than an elaborate portability > layer (or many many layers, or many many #ifdefs, which is gcc's technique). > in this case, however, after 15 or more architectures failed to change a copied section appreciably, > russ declared it portable after nearly 20 years, and moved it to ../cc the ifdefs mostly solve a different problem -- getting gcc to compile with different compilers, with different operating systems and different c libraries. that is not a problem that kenc addresses. gcc's "portability" from one arch to another is based on machine definitions, rtl (that goofy, lispy intermediate language gcc uses) and "backends". i'm fuzzy on how these interact, but i think the rtl+machine definition does the intermediate work, while a chip-family-specific backend does the actual code generation. so, since this is a stack-based email, the thesis comes last. i think the relationship between the code in ?c is similar to that in gcc. the major difference is that ?c is targets ? whereas it's not immediately clear what "gcc" targets. thus libtool uses i686-pc-linux-gnu-gcc. also ?c doesn't bother with an intermediate representation like rtl. - erik --upas-pplwizlhztzmhqkbfehdmhnfvc--