Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-sem!ron
From: ron@brl-sem.ARPA (Ron Natalie <ron>)
Newsgroups: net.lang.c
Subject: Re: Infinite loops
Message-ID: <203@brl-sem.ARPA>
Date: Sun, 4-May-86 13:20:01 EDT
Article-I.D.: brl-sem.203
Posted: Sun May  4 13:20:01 1986
Date-Received: Tue, 6-May-86 06:48:57 EDT
References: <117@brl-smoke.ARPA> <390@hadron.UUCP>
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 32

In article <390@hadron.UUCP>, jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
> 
> Unfortunately, as I'm sure many readers of this group will agree,
> not all compilers are reasonable.  The only one that consistently
> doesn't generate useless code is for (;;) {...}.
Joe, it is exactly this second guessing of compilers that get people in
trouble.  It is bad to make sweeping statements as to what is more efficient
because some compilers just do entirely unexpected, yet no more inefficient
things with code generation.

But the truth of the matter is, the PCC implementations get it right without
any optimization whatsoever.  Since most UNIX's use PCC as the base for their
C compilers, that generally solves the problem.
The original Ritchie compiler does miss it in the code generation, but the
optimzer removes the silly test.

Wait until the compiler comes out that does the following:

	for(;;)  { included code )

	L1:	NOP	/  init
	L2:	NOP	/  test
		INCLUDED CODE
		NOP	/  increment
		JUMP	L2

Frankly, if your compiler is so bad that it can't perform routine constant
elimination, than I doubt that you will really notice the extra performance
loss.  It's probably still multiplying out 60*60 for seconds in an hour
and other definitions.

-Ron