Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!pta!teti!teslab!andrew From: andrew@teslab.lab.OZ (Andrew Phillips) Newsgroups: comp.sys.amiga.tech Subject: Re: C compilers code generation Message-ID: <1159@teslab.lab.OZ> Date: 22 Nov 90 05:55:13 GMT References: <1149@teslab.lab.OZ> Reply-To: andrew@teslab.lab.oz.au (Andrew Phillips) Organization: Technology Evaluation Section, L.A.B., Sydney Lines: 25 In article dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >>In article <1149@teslab.lab.OZ> andrew@teslab.lab.OZ (Andrew Phillips) writes: > In the above code was Aztec and Lattice run in 32bit-int modes? > Probably, but just wondering...). They used 32 bit ints (the default). But this wouldn't matter, would it since the program only used shorts (16 bits) not ints. BTW I used no compiler options except to turn on maximum optimizations. With no command line options at all (i.e. all defaults) DICE did better than both Lattice and Aztec. > As far as the inner loop goes, I'm kind of proud of DICE in that it > does a pretty good job without any real optimization at all. Lattice > and Aztec could actually get more speed out of their code if they did > not use CLR. CLR always reads the location before writing a 0. According to my interpretation of the Motorola M68000 Microprocessor User's Manual (8th edition) pages 8-2 and 8-6 both instructions (i.e. CLR.B 0(A0,D0.W) and MOVE.B #0,0(A0,D0.W) ) take 18 clock cycles. Of course the CLR instruction is never BETTER than the equivalent MOVE #0. Andrew. -- Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 289 8712