Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!keith
From: keith@Apple.COM (Keith Rollin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Increment (Was Re: Pascal deficiency)?
Message-ID: <47576@apple.Apple.COM>
Date: 24 Dec 90 02:06:23 GMT
References: <33019.27737F47@stjhmc.fidonet.org>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 75

In article <33019.27737F47@stjhmc.fidonet.org> Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes:
>Marc T. Kaufman writes in a message to All
>
>MTK> I'm going to look at gcc and see if doesn't generate better 
>MTK> code. With the complexity of today's applications, every little 
>MTK> 5% helps. 

I took a look at one of the samples posted here compiled with both
MPW C and gnu C. This was the source:

void empty(int i) {};
main() { int i = 1; empty(++i); };

Under MPW C, we get the following:

empty():
00000000: 4E56 0000      LINK       A6,#$0000
00000004: 4E5E           UNLK       A6
00000006: 4E75           RTS        

main():
00000000: 4E56 0000      LINK       A6,#$0000
00000004: 2F07           MOVE.L     D7,-(A7)
0000000e: 7E01           MOVEQ      #$01,D7
00000008: 5287           ADDQ.L     #$1,D7
0000000A: 2F07           MOVE.L     D7,-(A7)
0000000C: 4EBA 0000      JSR        empty               ; id: 1
00000010: 2E2E FFFC      MOVE.L     -$0004(A6),D7
00000014: 4E5E           UNLK       A6
00000016: 4E75           RTS        

The LINK/UNLK in empty() is interesting. This doesn't occur under MPW
3.1 C, but it seems to be back in MPW 3.2 C. I'm not sure why.

Also, when compiling the sample, I got the warning from C that said
"Parameter "i" not used within the Body of the function :  empty"
However, when I removed "i" from the definition header, gC complained
with an error that "parameter name omitted".

Under gnu C, we get the following:

empty():
00000000: 4E75           RTS        

main():
00000000: 4878 0002      PEA        $0002
00000004: 4EBA 0000      JSR        empty               ; id: 5
00000008: 584F           ADDQ.W     #$4,A7
0000000A: 4E75           RTS        

Here, we see the same results that one other person noticed when
compiling on their NeXT block. Namely, that the i=1;++i; gets
optimized to "2". Another interesting thing is that empty() is
reduced to a simple RTS. Should an optimizing compiler recognize
that this is a null procedure, and remove the call to it altogether?

By the way, I also tried out gC on a much larger program. Compiled
under MPW 3.2 C, this program was 83K long. Under gC, the program
was 81K. Either:

a) MPW C is better than we thought
b) gC is not as good as we thought
c) the author of the program took advantage of constructs that lent
   themselves to being compiled better, no matter what the compiler was
   (I know that this alternative is not the case, though)
d) or the example I chose just happened to be a bad example ("bad", that
   is, for anyone trying to show that MPW C is a crummy compiler).


-- 
------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions