Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!zorch!amiga0!mykes
From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Compiler code (was a flame fest)
Message-ID: <mykes.1274@amiga0.SF-Bay.ORG>
Date: 3 Apr 91 02:32:39 GMT
References: <1991Apr2.100807.13471@ux1.cso.uiuc.edu>
Organization: Amiga makes it possible
Lines: 115

In article <1991Apr2.100807.13471@ux1.cso.uiuc.edu> cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) writes:
>In article <1991Apr2.002631.22799@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>>In article <mykes.1028@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>>>>char buf[20];
>>>>main()
>>>>{
>>>>  char *d=(char *)&buf;
>>>>  const char *s="This is a test\n";
>>>>  while(*s) { *d++=*s++; }
>>>>}
>>>>
>>>>/* Test.s produced by gcc */
>>>>
>>>>#NO_APP
>>>>gcc_compiled.:
>>>>.text
>>>>LC0:
>>>>	.ascii "This is a test\12\0"
>>>>	.even
>>>>.globl _main
>>>>_main:
>>>>	lea _buf,a1
>>>>	lea LC0,a0
>>>>	tstb a0@
>>>>	jeq L5
>>>>L4:
>>>>	moveb a0@+,a1@+
>>>>	tstb a0@
>>>>	jne L4
>>>>L5:
>>>>	rts
>>>>.comm _buf,20
>>><timing omitted>
>>>
>>>;/* test.s produced by me */		; (cycles)
>>>	lea	text(pc),a0		; 8
>>>	lea	buf(pc),a1		; 8
>>BUG! This is not the same algorithm in the C code. Your code would move
>>a NULL byte if a NULL string was passed when it should do nothing. I don't know
>>why GCC doesn't generate PC relative instructions, but I think it has to do
>>with UNIX and perhaps the scatter load/memory partitioning.
>>
>>>.loop	move.b	(a0)+,(a1)+		; 14*12
>>>	bne.s	.loop			; 13*10+1*8
>>>	rts				; 16
>>>text	dc.b	'This is a test',10,0
>>>buf	ds.b	20
>>>
>>  This code is compiled to run on a 68030 @ 50mhz, the difference in speed
>>would be _very_ small. Hey, someone compile this on SAS/C with ALL
>>optimizations on. You're just your average assembly language programmer
>>yet you introduced a subtle bug into the program that will stomp on the
>>first byte of a static global string by attempting to copy a null
>>string. In a HUGE program this bug would be so subtle that it may
>>take days to find out how a memory location is being sporatically
>>trashed. Worse yet, a null string will have garbage following it that could
>>span hundreds of bytes. 
>

WRONG!!!

I have eyes and could see that you aren't using a NULL string, and NO string
was "passed" to anything.  Your compiler should have had the same sense that
I do.  This program doesn't copy some arbitrary string.  If you would have
wrote the following code, both I and your compiler would have generated a
different assembler language program:

main() {
	char	*s = "some string";
	char	buf[20];

	CopyString(s, buf);
}

CopyString(s,d)
char	*s,*d;
{
	while(*s) { *d++=*s++; }
}

>As requested here is the SAS/C v5.10a generated code:
>
>
>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.
>


NOTE THE GOTCHA!!!!  My source would have assembled to the same
object code under any commercial assembler.


People who blindly use 'C' without understanding assembler language
are generating strange (meaning LONG) code in every program
they write.

--
********************************************************
* Appendix A of the Amiga Hardware Manual tells you    *
* everything you need to know to take full advantage   *
* of the power of the Amiga.  And it is only 10 pages! *
********************************************************