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.