Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!oddjob!hao!noao!mcdsun!sunburn!gtx!edge!doug
From: doug@edge.UUCP (Doug Pardee)
Newsgroups: comp.lang.c
Subject: Re: standardizing integral type sizes
Message-ID: <652@edge.UUCP>
Date: Thu, 16-Apr-87 12:16:12 EST
Article-I.D.: edge.652
Posted: Thu Apr 16 12:16:12 1987
Date-Received: Sun, 19-Apr-87 12:32:53 EST
References: <101@umich.UUCP> <791@xanth.UUCP> <1987Apr9.155110.28398@sq.uucp>
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 23

> The second thing is, yes, efficiency.  The Draft Standard DOES specify
> MINIMUM ranges for the different types.  In effect it guarantees...
> 
> 	char <= short <= int <= long
> 	char >= 8 bits, short >= 16 bits, int >= 16 bits, long >= 32 bits
> 
> ... with the further presumption, which has been part of C for a long
> time, that int operations are at least as efficient as other types.

I dunno about this last presumption having been part of C for a long time.
(I take that to mean K&R spec).  The closest I can find is in K&R sec. 2.2,
which says (twice) that "int" reflects the "natural size of integers on
the host machine."

I bring this up because on the C compilers I've used on the 68000, "int"
has always been a 32-bit quantity.  This is almost a necessity, because
of the well-known bad habit of assuming that a pointer will fit in an int.
But 32-bit ints on the 68000 are nowhere near as efficient as 16-bit ints.
They require twice as many memory accesses, and multiplication and division
have to be performed with subroutines.  This latter point can turn a simple
subscripting operation into a performance catastrophe.

-- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona