🚀 go-pugleaf

In article <1159@teslab.lab.OZ> andrew@teslab.lab.OZ (Andrew Phillips) writes:
>In article <dillon.7176@overload.Berkeley.CA.US> 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