Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Compiler code (was a flame fest)
Message-ID: <1991Apr2.120416.4378@mintaka.lcs.mit.edu>
Date: 2 Apr 91 12:04:16 GMT
References: <1991Apr2.100807.13471@ux1.cso.uiuc.edu>
Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius)
Organization: The Internet
Lines: 78

In article <1991Apr2.100807.13471@ux1.cso.uiuc.edu> cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) writes:
>Using:	`lc -v -O -b0 test.c'
>	`omd test.o'
><begin test.c>
>// Same program with GNU coding style enforced...
>char buf[20];
>
>void main (void)
>{
>  char *d = (char *)&buf;
>  char *s = "This is a test\n";  // Note I got rid of the const, as
>				 // not only is it of questionable
>				 // legality under ANSI C (YOU CHANGE THE
>				 // VALUE OF s!), but also caused SAS/C
>				 // to generate (good, but) strange
>				 // (meaning LONG) code.
  You're right. I had a strange feeling that GCC would try to put
*s on the stack, so I made it const (static produces worse code).
I never really use const myself except to help generate compiler warnings
in some routines that I suspect of corrupting variables. Oddly enough, GCC
doesn't give a warning for the '*s++' which is a changing const. I now
find out that GCC produces the same code without the const. :-(

>
>  while (*s)
>    *d++=*s++;
>}
><end test.c>
>
>Lattice AMIGA 68000-68020 OBJ Module Disassembler V5.04.039
>Copyright ) 1988, 1989 Lattice Inc.  All Rights Reserved.
>
>
>Amiga Object File Loader V1.00
>68000 Instruction Set
>
>EXTERNAL DEFINITIONS
>
>_main 0000-00    _buf 0000-02
>
>SECTION 00 "test.c" 00000020 BYTES
>       | 0000  48E7 0030                      MOVEM.L   A2-A3,-(A7)
>       | 0004  47F9  0000 0000-02             LEA       02.00000000,A3
>       | 000A  45F9  0000 0000-01             LEA       01.00000000,A2
>       | 0010  6002                           BRA.B     0014
>       | 0012  16DA                           MOVE.B    (A2)+,(A3)+
>       | 0014  4A12                           TST.B     (A2)
>       | 0016  66FA                           BNE.B     0012
>       | 0018  4CDF 0C00                      MOVEM.L   (A7)+,A2-A3
>       | 001C  4E75                           RTS

 Hmm, is it standard practice of SAS/C to preserve a2-a5? I think it should
use a0/a1 as scratch registers. Try compiling it with a small data/code
option and it might make those lea's PC relative. BTW, I compiled
the code using DICE and DICE does a link a5,#0/unlk a5 which does nothing.
It should omit the frame pointer.

>SECTION 01 " " 00000010 BYTES
>0000 54 68 69 73 20 69 73 20 61 20 74 65 73 74 0A 00 This is a test..
>
>SECTION 02 " " 00000014 BYTES
>
>This compares quite nicely to GCC and the buggy asm code given above :-).
Hmm. Look's like I'll be purchasing SAS/C soon. :-)

>Loren J. Rittle
>-- 
>``NewTek stated that the Toaster  *would*  *not*  be made to directly support
>  the Mac, at this point Sculley stormed out of the booth...'' --- A scene at
>  the recent MacExpo.  Gee, you wouldn't think that an Apple Exec would be so
>  worried about one little Amiga device... Loren J. Rittle  l-rittle@uiuc.edu


--
/~\_______________________________________________________________________/~\
|n|   rjc@albert.ai.mit.edu   Amiga, the computer for the creative mind.  |n|
|~|                                .-. .-.                                |~|
|_|________________________________| |_| |________________________________|_|