Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!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: <1991Apr3.042457.3703@mintaka.lcs.mit.edu> Date: 3 Apr 91 04:24:57 GMT References: <1991Apr2.100807.13471@ux1.cso.uiuc.edu> Sender: news@mintaka.lcs.mit.edu Organization: The Internet Lines: 128 In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >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: >>> 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: Mike, you still don't get it. YOUR CODE used a different algorithm, but our comparision was supposed to be based on comparisions of the same algorithm. Your code was not the same as 'while (*s) *d++=*s++;'. Your code was equivelent to 'do *d++=*s++; while(*s);' Again, someone with SAS/C compile the do/while version and I bet it will leave out the starting 'bra'. That's the reason I gave the 'boyer more in C vs brute force in assembly' example because you weren't comparing the same algorithms. >main() { > char *s = "some string"; > char buf[20]; > > CopyString(s, buf); >} > >CopyString(s,d) >char *s,*d; >{ > while(*s) { *d++=*s++; } >} GCC and SAS/C would have 'inlined' these functions when optimizing for speed. The point is, you did not translate my algorithm into proper ASM code. >>As requested here is the SAS/C v5.10a generated code: >> >> >>Using: `lc -v -O -b0 test.c' >> `omd test.o' >> >>// 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. gcc_compiled.: .text LC0: .ascii "This is a test\12\0" .align 4 .global _main .proc 1 _main: !#PROLOGUE# 0 save %sp,-80,%sp !#PROLOGUE# 1 sethi %hi(_buf),%o2 or %lo(_buf),%o2,%o2 sethi %hi(LC0),%o1 b L6 or %o1,%lo(LC0),%o1 L4: ldsb [%o1],%o3 stb %o3,[%o2] add %o1,1,%o1 add %o2,1,%o2 L6: ldsb [%o1],%o0 tst %o0 bne L4 nop ret restore .global _buf .common _buf,24,"bss" Here's the GOTCHA. This code became optimized RISC assembler instructions on a SPARCStation. >People who blindly use 'C' without understanding assembler language >are generating strange (meaning LONG) code in every program >they write. Most professional developers who use C to do system level, low-level code understand assembler and the hardware they are working on. If they don't, it's likely that what they are coding doesn't need assembler. Even Jeremy San prototypes his games in C before coding in assembler. He also codes his tools in C (he said it himself on BIX). >-- >******************************************************** >* 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! * >******************************************************** -- /~\_______________________________________________________________________/~\ |n| rjc@albert.ai.mit.edu Amiga, the computer for the creative mind. |n| |~| .-. .-. |~| |_|________________________________| |_| |________________________________|_|