Xref: utzoo comp.lang.c:5927 comp.sys.m68k:650
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!alberta!teletron!andrew
From: andrew@teletron.UUCP (Andrew Scott)
Newsgroups: comp.lang.c,comp.sys.m68k
Subject: Re: C machine
Message-ID: <166@teletron.UUCP>
Date: 31 Dec 87 19:58:30 GMT
References: <7535@alice.UUCP> <8226@steinmetz.steinmetz.UUCP> <461@auvax.UUCP> <9961@mimsy.UUCP>
Organization: TeleTronic Communications Ltd., Edmonton, Alta.
Lines: 28
Summary: What is "natural" ?

I've got a related question to this discussion thread; I've crossposted to
comp.sys.m68k also.

In article <9961@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> I would say that, if the machine has a 64 bit address space and 64
> bit arithmetic, but the `natural' arithmetic size is 32 bits, it
> is 32 bits; otherwise it is 64.  I would make longs 64 (or perhaps
> even 128) bits, and shorts quite possibly still 16 bits.  It would
> be nice to have 8, 16, 32, and 64 bit values, and it seems natural
> to make those `char', `short', `int', and `long' respectively.  This
> might be a problem for program that assume either short==int or
> long==int, though.

What should be the compiler writer's criteria for selecting the "natural"
size for the above C types?  Should it be bus size, internal register size,
or something else.  Our 68000 compiler has 16 bit shorts, 32 bit longs (which
make sense) and 32 bit ints (which doesn't always make sense).

A lot of code I've come across uses scratch variables (array indices etc.) of
type int.  Of course, 32 bit arithmetic must be used.  However, the 68000 has
16 bit divide and multiply instructions, which are *much* faster than the 
subroutine calls to the 32 bit arithmetic routines.  The case could be made
that a 16 bit quantity is the "natural" size for arithmetic operations for
the 68000.

Why would a compiler vendor for the 68000 choose a 32 bit size for an int?

	Andrew			(..alberta!teletron!andrew)