printf() code size using Astartup.obj and AMIGA.LIB only

[mwm at eris.berkeley.edu]

In article <1385 at well.UUCP> ewhac at 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