Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site smu Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!smu!mike From: mike@smu Newsgroups: net.micro.mac Subject: Re: slow C compilers Message-ID: <20800041@smu> Date: Mon, 16-Sep-85 14:06:00 EDT Article-I.D.: smu.20800041 Posted: Mon Sep 16 14:06:00 1985 Date-Received: Sun, 29-Sep-85 04:48:39 EDT References: <417@decwrl.UUCP> Lines: 21 Nf-ID: #R:decwrl.UUCP:-41700:smu:20800041:000:1001 Nf-From: smu!mike Sep 16 13:06:00 1985 There's sort of a problem with the idea of an extensiveley optimizing C compiler. First, some of the optimizations mentioned (code hoisting, common subexpression elimination (I suppose beyond basic blocks), and various loop optimizations) take a lot of space (in general). Maybe you're willing to pay this price. The other (and real) problem is that C, because of its low-level (I don't really like that term) nature, is not supposed to be thusly optimized. Check pages 49 and 50 of K&R. I suppose I would sort of lke an optimizing compiler as well, but I've gotten pretty good at writing the source code efficiently to begin with (some would say this is a bad habit, but most of my life is pretty sleazy anyway so this doesn't bother me). I remember a possibly apocryphal story I heard in a compiler class about a guy who wrote a FORTRAN source code optimizer that was more effective than IBM's FORTRAN G (or maybe H, whichever is the good one). Mike McNally SMU mike@smu ...convex!smu!mike