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."