Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site mako.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!orca!mako!seifert
From: seifert@mako.UUCP (Snoopy)
Newsgroups: net.unix-wizards,net.lang.c
Subject: Re: integer types, sys calls, and stdio
Message-ID: <550@mako.UUCP>
Date: Wed, 30-Jan-85 00:21:48 EST
Article-I.D.: mako.550
Posted: Wed Jan 30 00:21:48 1985
Date-Received: Wed, 30-Jan-85 06:49:17 EST
References: <1997@mordor.UUCP> <631@turtlevax.UUCP>
Reply-To: seifert@mako.UUCP (Snoopy)
Distribution: net
Organization: The Daisy Hill Puppy Farm
Lines: 83
Keywords: medium-longish-int
Xref: watmath net.unix-wizards:11775 net.lang.c:4077
Summary: Snoopy disagrees with Ken, and offers possible solution to
Summary: problem of porting code to machines with funny word sizes

In article <631@turtlevax.UUCP> ken@turtlevax.UUCP (Ken Turkowski) writes:
>In article <1997@mordor.UUCP> jdb@mordor.UUCP (John Bruner) writes:
>>Here at the S-1 Project at LLNL we are porting UNIX to our own
>>machine, the S-1 Mark IIA.  The hardware is capable of operating
>>upon 9-bit, 18-bit, 36-bit, and 72-bit quantities, so we have
>>defined the following types:
>>
>>	char	= 9 bits	(S-1 quarterword)
>>	short	= 18 bits	(S-1 halfword)
>>	int	= 36 bits	(S-1 singleword)
>>	long	= 72 bits	(S-1 doubleword)
> ...
>>We can define our system calls to use "int" and "long" integers as
>>V7 does, but this means that we'll have to use 72-bit integers when
>>a 36-bit integer would nearly always suffice.  This seems ugly to me.
> ...
>
>Chars have always been 8 bits, shorts always 16, and longs always 32.

I wouldn't bet my life on it.  Look in K&R. (page 182 in my copy)

>I would suggest that you keep as close to this as possible.  Int has
>varied between 16 and 32 bits; hell, why not make it 64? :-)
>viz,
>
>	char	= 9 bits	(S-1 quarterword)
>	short	= 18 bits	(S-1 halfword)
>	long	= 36 bits	(S-1 singleword)
>	int	= 72 bits	(S-1 doubleword)

"int" longer than "long"?  You are hereby sentenced to program
in FORTRASH for six months!

-----------  new (?) idea begins here  --------------------

OK, here's my suggestion, which may not help John (Hi John!)
port existing code, but might help in the future.

Why not figure out how many bits each variable *needs*, and then
declare them accordingly:

int8	foo;
int16	bar;
int12	baz;
int9	buff[BUFFSIZ];
int18	blat;

Then when the mess gets compiled, the various size ints get changed
to the smallest possible machine entity size, on the machine
it's getting compiled for.

So then when you're porting some spiffo program developed on,
say, a pdp11 to say, a pdp8, with 12 bit words, "baz" fits nicely.
You don't have to *assume* that it really might need 16 bits.

"blat", which is just a tad too big for a 16 bit int, would fit
in a "short" on the S-1 Mark IIA.  It it had been declared "long",
it would get 72 bits! (are we talking overkill, or what?)

(I *refuse* to use the CDC with it's 6 bit characters and no lower case
as an example, so there!)

If speed is more important than storage, one could use a "fast"
suffix:

int14f	foobar;

This would clue the compiler/preprocessor/sed-script/whatever to
use the fastest size (if it fits), even if it fits in something smaller.
or, there's always:

register int14 foobar;

That's it.  Pretty simple.  (therefore it might work, but noone will
like it  :-)  )  Again, yes I realise this doesn't help with *existing*
code, but it would help to use it in new stuff, no?  And it doesn't
require an extension to the language!

        _____
	|___|		the Bavarian Beagle
       _|___|_			Snoopy
       \_____/		tektronix!mako!seifert
        \___/