Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!adm!guy%gorodish@Sun.COM
From: guy%gorodish@Sun.COM
Newsgroups: comp.lang.c
Subject: Re: standardizing integral type sizes
Message-ID: <6998@brl-adm.ARPA>
Date: Tue, 21-Apr-87 09:29:35 EST
Article-I.D.: brl-adm.6998
Posted: Tue Apr 21 09:29:35 1987
Date-Received: Wed, 22-Apr-87 02:47:31 EST
Sender: news@brl-adm.ARPA
Lines: 19

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

"Almost".  I worked on a 68000-based machine that had a C
implementation 16-bit "int"s and 32-bit pointers; I didn't find it
particularly painful to use, except when I had to fix other people's
code to be type-correct (and I knew enough to blame *that* on the
other people who wrote that code, not on the C implementation).

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

Nope.  Multiplication by a constant can be done in-line, with a
sequence of shifts and adds, and the most common type of
multiplication in subscripting operations is multiplication by a
constant.