Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!sri-spam!nike!ucbcad!ucbvax!jade!eris!mwm
From: mwm@eris.berkeley.edu
Newsgroups: net.micro.amiga,net.lang.c
Subject: Re: printf() code size using Astartup.obj and AMIGA.LIB only
Message-ID: <951@jade.BERKELEY.EDU>
Date: Tue, 8-Jul-86 15:26:25 EDT
Article-I.D.: jade.951
Posted: Tue Jul  8 15:26:25 1986
Date-Received: Thu, 10-Jul-86 01:08:50 EDT
References: <8606270438.AA07486@pavepaws> <426@oscvax.UUCP> <84@unisoft.UUCP> <566@3comvax.UUCP> <1385@well.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.UUCP ()
Followup-To: net.lang.c
Organization: Missionaria Phonibalonica
Lines: 47
Xref: watmath net.micro.amiga:3895 net.lang.c:9775

In article <1385@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>	It never fails to amaze me just how many people do this:
>		if (foo == NULL) { ... }
>	or:
>		if (foo == 0) { ... }
[instead of...]
>		if (!foo) { ... }

Well, I wrote it the way you think people ought to for 8 years before
changing to coding the test explicitly. I changed because the (!foo)
notation is less readable than the (foo == 0) notation.

Also, if foo is a pointer type, the test (!foo) is wrong. NULL doesn't
have to be zero.

>	The reason the compiler is exhibiting the behavior you describe is
>because you told it to.  You are asking the compiler to compare an unsigned
>byte to the literal value of NULL.

Uh, what he got was:

>>causes var to be first loaded, extended to a word, extended to a long, then
>>compared against 0, EVEN when var is declared as a UBYTE...

What's the second extend doing in there? Anything claiming to be a
reasonable compiler should generate ONE extend. Anything claiming to
be not bad (much less good) should realize what's going on, and
generate the CMP.B instruction. Of course, a good compiler will check
to see if the Z condition code is set correctly already (from a move
to/from var, or the evaluation into var), and just generate the
branch. If it's slightly intelligent, it'll be willing to re-arrange
code to make that pre-condition happen.

>	If you *really* care about optimized code, compile to an assembly
>source file and bang on it yourself.  That's something Lettuce *definitely*
>won't let you do.

Well, I'd rather get the source to the compiler and bang on that so it
generates good code (that way I only have to do it once). But I expect
the compiler to at least generate non-abysmal code.

>>Oh, well... I guess someone will make a good 'C' compiler someday...

DEC has one for VMS. Convex has one for their box (though it may not
be released yet). Anybody know of any others?

	<mike