Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site lzmi.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!drutx!ahuta!pegasus!lzmi!psc
From: psc@lzmi.UUCP (Paul S. R. Chisholm)
Newsgroups: net.micro.mac
Subject: Re: Re: C Compiler Benchmarks
Message-ID: <334@lzmi.UUCP>
Date: Mon, 4-Mar-85 21:57:17 EST
Article-I.D.: lzmi.334
Posted: Mon Mar  4 21:57:17 1985
Date-Received: Wed, 6-Mar-85 04:34:26 EST
References: <189@cadtroy.UUCP>
Organization: AT&T-IS Enhanced Network Services
Lines: 25

>> 2.  Bill points out that the Megamax compiler uses 16 bit integers, while
>>     his compiler uses 32 bit integers.  When the Consulair compiler used
>>     16 bit integers in the sieve program the run time with his old compiler
>>     was 6.3 seconds.
>
>Hmmm,  the 68000 inside the MAC has a 24bit address space.  A AT&T
>68010 UNIX distribution C compiler believes that ints are 16bits.

The Gosphel According to Richie states "'Plain' integers have the natural
size suggested by the host machine architechture; the other sizes are
provided to meet special needs.

AT&T has two 68000 compilers:  one generates 16 bit ints, the other, 32
bit.  A friend (and former supervisor) of mine chose the former for his
boss's extremely non-trivial 68000 based project.  The 16 bit machine
produces code that is 10% smaller and 10% faster (my failing memory may
be underexaggerating).  Aside from being *very* careful not to store a
pointer in an int, everything went fine.  (BTW, normal lint will not
catch this error; it has PDP-11isms hardwired into it.  Oddly enough,
my first assignement for this guy was to fix lint so it understood
VAXes; helped him a lot when he went to the 68000.)
-- 
	-Paul S. R. Chisholm
	...!{pegasus,cbosgd}!lzmi!psc   The above opinions are my own,
	...!{hocsj,ihnp4}!lznv!psc      not necessarily anyone else's.