Newsgroups: comp.robotics,sci.electronics
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!sol.ctr.columbia.edu!news.msfc.nasa.gov!news.larc.nasa.gov!xanth.cs.odu.edu!maui.cc.odu.edu!hearst.acc.Virginia.EDU!maxwell!gr3k
From: gr3k@Virginia.EDU (Gregory P. Riddick)
Subject: Re: BASIC STAMP ALTERNATIVES--THE STATE OF PLAY
Message-ID: <D9o7L2.n4C@Virginia.EDU>
Organization: University of Virginia
References: <3qlk40$h5h@cdn_mail.telecom.com.au>
Date: Sun, 4 Jun 1995 22:53:25 GMT
Lines: 24
Xref: glinda.oz.cs.cmu.edu comp.robotics:21403 sci.electronics:135120

PJR writes "All a compiler does is convert your code to
assembly," and wonders why some people claim that a compiler
often produces less efficient code than straight assembly.
  Compilers have two main goals. (1) Is to produce correct code 
(2) Is to produce the most efficient code possible.  In
generating correct code, a compiler assumes that the most
general case for any given statment is always true.  In other
words, it has to use general-purpose algorithms that sacrifice
efficiency for correctness. Here's an example:

While x+25>y do begin

y=y+1

end

A non-optimizing compiler while assume the most general case
and will evaluate x+25 with every pass of the loop.  An
optimizing compiler will recognize that the value of x doesn't
change within the loop, and will only evaluate x+25 one time,
store that value, and compare it with y in each pass. And
unless the end-user has an intimate knowledge of a how the
compiler generates code,even a heavily optimized compiler will
fall short of an exprienced assembly language programmer.
