Path: utzoo!utgpu!water!watmath!uunet!tut.cis.ohio-state.edu!cwjcc!mailrus!rutgers!labrea!agate!helios.ee.lbl.gov!lll-tis!lll-winken!killer!vaxnix!ron
From: ron@vaxnix.tandy.COM (Ron Light)
Newsgroups: gnu.gcc.bug
Subject: Re: GCC 1.30 complaints
Message-ID: <1608@vaxnix.tandy.COM>
Date: 24 Oct 88 18:14:05 GMT
References: <8810220131.AA00312@ucsci.ucsc.edu> <1531@vaxnix.tandy.COM> <9773@bigtex.cactus.org>
Reply-To: ron@vaxnix.UUCP (Ron Light)
Distribution: gnu
Organization: VideOmega Inc. - Ft. Worth Texas
Lines: 17

In article <9773@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes:
>Surely you don't seriously expect that kind of loop to work?  Good
>Lord, even if you figure out the right constants for a particular
>compiler on a particular machine, what happens when Tandy builds a
>33MHz 386, or GNU C v2.0 generates code twice as good as v1.30, or you
>switch to some other compiler or CPU altogether?


Your point is well taken, John, and I would never use such a loop for
anything that was even close to timing critical or important.  But my
discussion was for the purpose of an example of why a loop is sometimes
necessary.  If I have a delay loop, for whatever reason, I would be very
angry if the compiler decided, for itself, "Oh, this is stupid, we don't
need this."  A compiler's job is not to make higher level decisions on what
it thinks I want, or do not want.  It's job is to take the source code I've
given it and try to produce the most reasonable approximation of assembly
or binary code.  In the original example given, I find that a=100 is about
as far away from what was intended as one can possibly get.