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

moss@cs.umass.edu (Eliot Moss)
Wed, 13 Jun 90 14:39:51 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)
[11 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: moss@cs.umass.edu (Eliot Moss)
References: <1990Jun12.163959.2593@esegue.segue.boston.ma.us>
Date: Wed, 13 Jun 90 14:39:51 GMT
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Keywords: code, optimize
In-Reply-To: holub@violet.Berkeley.EDU's message of 12 Jun 90 16:39:59 GMT

While I agree with your characterization of the philosophy of C, I strongly
disagree with this remark:


        If you don't like this philosophy, there are scores of safer
        (slower, less-powerful) languages that will hold you hand and not let you
        do something stupid.


The reason I disagree is that it promulgates the false belief that safety is
inefficient. Sometimes being safe requires writing down more (e.g., declaring
more about types), but the extra keystrokes almost certainly pay off in the
long run by reducing debug and maintenance effort. More importantly, 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, as sometimes happens when writing low level systems code
(e.g., manipulating memory mapped I/O device registers). I would also like to
point out that optimizations techniques are known that can eliminate most
array bounds checks, if bounds checking is one of the safety measures that
concerns you. Further, loop optimizations are known that will effectively
transform a[i] forms in a loop into *p, *p++, etc., forms, so it is not even
fair to claim that one must sacrifice the efficiency of direct pointer
manipulation. Granted these optimizations cannot be performed all the time,
but a lot of code *is* amenable to them, *and* they can be done safely.


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 believe that you can be safe *and* fast, because there has been
and continues to a lot of good work on optimization techniques to remove any
reasonable objection to safety features in programming languages.
--


J. Eliot B. Moss, Assistant Professor
Department of Computer and Information Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206; Moss@cs.umass.edu
--


Post a followup to this message

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