Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.lang.c
Subject: Re: Infinite loops
Message-ID: <2717@utcsri.UUCP>
Date: Tue, 6-May-86 11:27:45 EDT
Article-I.D.: utcsri.2717
Posted: Tue May  6 11:27:45 1986
Date-Received: Tue, 6-May-86 12:31:59 EDT
References: <117@brl-smoke.ARPA> <390@hadron.UUCP> <203@brl-sem.ARPA>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 79
Summary: 

In article <203@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes:
>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.
...
>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
>

Well, it's even worse... Consider C/80, a subset C compiler for 8080's
[ no floats, longs, structs, unions, **s, :-( ]:

	for( e1;e2; e3 ){
becomes
		<e1>
	f0:	<e2>
		JZ	f3
		JMP	f2
	f1:	<e3>
		JMP	f0
	f2:	<loop code>
		JMP	f1
	f3:

So for(;;) just reduces to

	f0:	JMP	f2
	f1:	JMP	f0
	f2:	<loop code>
		JMP	f1

Really! The compiler apparently cannot save <e3> until later; it doesn't
build trees. It also pushes function args left-to-right ( another story ).

while(1), on the other hand, becomes

	w0:	LXI	H,1	; evaluate 1 ( in 16-bit reg HL )
		MOV	A,H	; test HL by ORing the upper
		ORA	L	;	and lower bytes to the ACC
		JZ	w1	;	( standard 8080 idiom )
		<loop>
		JMP	w0
	w1:

>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.

C/80 is ( using a 'mult' subroutine, of course. a<b uses a 'lt' subroutine ).

I have written a large amount of code with this beast - including an
`optimizing assembler' to cure many of the horridities emitted by the
compiler.

Sorry, I know, this should be in net.lang.brain.damaged. If you don't
flame me, I promise never to mention this compiler again :-).

P.S. There is an 8088 version of the compiler - I don't know if it is
any better ( or worse ).

-- 
"Canabee be said2b or not2b anin tire b, if half thabee isnotabee, due2
somain chunt injury?" - Eric's Dilemma
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg