Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: C compilers code generation Message-ID: Date: 27 Nov 90 22:02:49 GMT References: <1149@teslab.lab.OZ> <1159@teslab.lab.OZ> Lines: 68 In article <1159@teslab.lab.OZ> andrew@teslab.lab.OZ (Andrew Phillips) writes: >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. Actually, it can matter. A 16 bit compiler does not need to optimize arithmatic expressions at all. A 32 bit compiler such as Lattice / DICE must start out by virtual EXTing the 16 bit quantities to 32 bits and then optimize them back down to 16 bits. There are many expressions that cannot be optimized. It does not matter whether, for 16 bit compilation, one uses 'short' or 'int', they are identical (just as 'int' and 'long' are identical for 32 bit compilers). For example: short a, b; foo (a * b); /* 16 bit argument for 16 bit compiler, 32 bit * argument for 32 bit compiler */ Another good example is array indexing. Most IBM C compilers use 16 bit indexes for array indexing and ignore possible overflows (i.e. you have an array 65536 of short). Turbo C on the IBM is even worse... it uses a 16 bit array index even if you use a long quantity as the index! As far as I know, all Amiga C compilers (Aztec,Lattice,DICE), use 32 bit array indexes when forced to multiply by 2 or more for non-char arrays. Yet another is the question of bit field packing ... do you pack in 16 bit fields when ints are 16 bits, even if your compiler supports 32 bit ints (i.e. disallows bit fields larger than 16 bits wide when in 16 bit mode?) These are simple examples, of course, but you get the idea. There are many differences between 16 bit and 32 bit implementations. I'm not arguing or anything, I'm rather pleased myself! >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. That is very interesting. One of DICE's big points is that compilation time is at least as fast as Aztec (haven't tested it formally). It is definitely much faster than Lattice. Lattice has always taken a while to do compiles, and with the -O option it goes even slower! Personally, I've never trusted Lattice's -O option having been personally bitten by bugs in previous versions of Lattice C (5.02). I dunno about later versions because I stopped using the option. I have no experience with Aztec's optimization options. >Andrew. >-- >Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 289 8712 -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA