Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!ron From: ron@brl-tgr.ARPA (Ron Natalie) Newsgroups: net.lang.c Subject: Re: int16, int32 Message-ID: <738@brl-tgr.ARPA> Date: Fri, 16-Aug-85 00:05:47 EDT Article-I.D.: brl-tgr.738 Posted: Fri Aug 16 00:05:47 1985 Date-Received: Mon, 19-Aug-85 08:40:58 EDT References: <719@brl-tgr.ARPA> Organization: Ballistic Research Lab Lines: 23 > >I'd like to further point out that one of the machines I have access to has > >the following: > > > > char: 8 bits > > short: 32 bits > > int: 64 bits > > long: 64 bits > > > >The machine (Control Data Cyber 180/855) doesn't support 16-bit arithmetic > >very well, which is why shorts aren't 16-bits, ints aren't 32 bits and longs > >aren't 64 bits. > > > > robert When BRL did the C compiler for the Denelcor HEP, shorts are 16, ints and longs are 64 (the word size). The HEP can calculate just fine on 8, 16, 32, or 64 bit quantities. However, ints really need to be 64. This was solved by adding another integer type "medium" (actually, called _int32), which no one except the kernel hackers need to know about. -Ron I wanted to call them "short longs."