Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site plus5.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!plus5!eric From: eric@plus5.UUCP (Eric W. Kiebler) Newsgroups: net.micro.mac Subject: Re: Re: C Compiler Benchmarks Message-ID: <620@plus5.UUCP> Date: Sun, 3-Mar-85 15:30:17 EST Article-I.D.: plus5.620 Posted: Sun Mar 3 15:30:17 1985 Date-Received: Mon, 4-Mar-85 20:27:16 EST References: <5124@ucbvax.ARPA> <189@cadtroy.UUCP> Organization: Plus Five Computer Services, St. Louis Lines: 88 > > This is an excellent point. I neglected to notice whether the other > > compilers used 16 or 32-bit integers. Someone told me that the C > > standard stipulates that an integer's worth of bits must be able > > to span the entire address space. I don't know about this. Can > > someone comment? > > Hmmm, the 68000 inside the MAC has a 24bit address space. A AT&T > 68010 UNIX distribution C compiler believes that ints are 16bits. > > marty > schoff@cadmus.ARPA > {wanginst,seismo}!ucadmus!schoff Which standard? IEEE/usr/group standard? So what if AT&T believes ints are 16 bits? White Book page 102, section 5.6, says "5.6 Pointers are not Integers". Page 34 says: int an integer, typically reflecting the natural size of integers on the host machine. This would appear to be 16 bits, eh? That is, of course, if you consider MOVE.L unnatural... Now, the C Reference Manual, section 4, states "Types CHAR and INT of all sizes will collectively be called INTEGRAL TYPES". Then, section 14.4 states "An object of integral type may be explicitly converted to a pointer. The mapping always carries an integer converted from a pointer back to the same pointer, but is otherwise implementation independent". So, if we consider a long int at 32 bits to be an integral type, then 16 bit ints are swell. Now, section 6.4 states "Two pointers to objects of the same type may be subtracted; in this case the result is converted to an integer as specified in the discussion of the subtraction operator." What does this all mean? If the result of pointer subtraction is 16 bits, the number of objects in an array is limited to 64K. This, as it were, sucks. The only guarantee for longs is that they aren't shorter than shorts, so they may in fact be 16 bits. So, a resolution of the problem for the 68K is to make the result of pointer subtraction an integral type as opposed to an integer, and to make ints 16 bits, chars 8 bits, and longs 32 bits. That way, compiler writers could still follow the standard and we could still access the entire address space of the machine using pointer expressions. If you don't think that people should use arrays that big then your mom was right, you're never going to amount to anything, and you smell bad, too :-). On the other hand, making the result of pointer subtraction a long (which is what would be required) makes passing the result of pointer subtraction non-backward-compatible with existing programs. A long does not get converted to an int when being passed as an actual parameter, so people who code things like ... int a[100000], *pia, *pib; pia = a+10; pib=a+99999; ... plop(pib-pia); ... plop(dif) int dif; {...} are going to be very disappointed. I am sure there are other examples of this kind of problem. I like 32 bit ints, myself; I don't want to fix all those old programs, and I want to access big arrays. I will live with the speed difference. I don't have my copy of the proposed /usr/group standard -- did they fix this somehow? eric PS. I know this was flying around in net.unix* a while ago, but I didn't care back then because I was using a VAX :-). -- ..!ihnp4!wucs!plus5!eric ..!ihnp4!plus5!eric (314) 725-9492