Re: Unsafe Optimizations (formerly Compiler Design in C...)

holub@violet.Berkeley.EDU ()
Thu, 14 Jun 90 03:19:36 GMT

          From comp.compilers

Related articles
Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-12)
Re: Unsafe Optimizations (formerly Compiler Design in C...) moss@cs.umass.edu (1990-06-13)
Re: Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) marti@inf.ethz.ch (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) larus@primost.cs.wisc.edu (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) grover@brahmand.Eng.Sun.COM (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) MERRIMAN@ccavax.camb.com (George Merriman -- CCA/NY) (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) pardo@june.cs.washington.edu (1990-06-15)
[10 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: holub@violet.Berkeley.EDU ()
References: <1990Jun12.163959.2593@esegue.segue.boston.ma.us> <1990Jun13.143951.2129@esegue.segue.boston.ma.us>
Date: Thu, 14 Jun 90 03:19:36 GMT
Organization: University of California, Berkeley
Keywords: code, optimize

In article <1990Jun13.143951.2129@esegue.segue.boston.ma.us>
moss@cs.umass.edu (Eliot Moss) writes:


>...it is not that hard to design languages that as a default prevent you from
> using pointers to stomp all over memory, but still allow you do it when you
> explicitly need to...


True, but let's separate the academic ideal from the real situation. Most
computer programs are written in a handful of existing languages and it's a
long road to getting the programming community to accept a new language,
regardless of its merits. The real cost (in dollars) of changing a progamming
language in a large shop is staggering. The question is not whether it's
possible to create a new, safer language; but rather, given the framework of
existing languages and the limitations of the platforms on which those
languages must be implemented (IBM PCs, Macs, etc. represent the vast
majority ---CRAYs and VAXs are the minority), does the compiler writer have
any business deliberately restricting what the programmer can do simply
because he or she doesn't think that the programmer has enough sense not to
use a feature when it's not safe. I think not.


>While we, as instructors, researchers, experts, and practitioners, may
>understand a lot of this, I feel it very important that it be conveyed to our
>students.


I agree with this too, which is why I discuss an unsafe optimization in the
book. In any event, I do find it strange that the only part of the book that
has engendered any controversy on the net is one sentence in a very small
chapter (22 pages out of 924) that was meant only to serve as a short
introduction to the vast field of optimization. "Compiler Design in C" is an
attempt to make compiler front-end theory and practice accessible to working
programmers and students who would rather read English than mathematical
jargon, and I think that the book succeeds in doing so. Conveying fine points
of philosophy to our students is very important, but so is getting across a
basic understanding of how to construct computer programs--in this case,
compilers. It is the place of the teacher to do both, but the textbook needs
only to do the latter--at least I often disagree with statements in texts
that I use, and I make a point of telling my students both why I disagree and
what I think is the correct point of view. I strongly believe that this sort
of discussion, often used in the humanities but rarely in engineering and the
hard sciences (at least at the undergraduate level), is a wonderful pedagogic
tool and wish it was used more often.


-Allen Holub
  holub@violet.berkeley.edu
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.