Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!phil
From: phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN)
Newsgroups: comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <1991May24.064241.26159@ux1.cso.uiuc.edu>
Date: 24 May 91 06:42:41 GMT
References: <1991May6.232116.11401@sq.sq.com> <1991May9.192156.19291@nightowl.MN.ORG> <313@orac.UUCP> <6659@gssc.UUCP>
Organization: University of Illinois at Urbana
Lines: 28

timr@gssc.UUCP (Tim Roberts) writes:

>What if your 64 bit architecture doesn't have any instructions to deal with
>16 bit units?  You certainly aren't going to include something as a fundamental
>type when your architecture can't easily deal with it, are you?  What if, going
>further, you can't manipulate 32 bit objects either?  On such a machine, you
>would probably create short=int=long=64 bits.

I believe the discussion centered around machines that indeed could
manipulate quantites in all the sizes.  But you do have a valid point.
The concern I have in the matter is whether or not the capability to
manipulate quantites in 64-bit sizes is left out of the standardized
part of C.

>The point is this:  C data types are intended to map into the fundamental
>operating units of the underlying hardware.  Discussing the correctness of
>C data type sizing on 64-bit machines in the general case is a pointless waste 
>of network bandwidth.

I believe C requires:  short <= int <= long

But it is also suggested that the fundamental unit be defined as "int",
not as "long".  Which way would you go?
-- 
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/