Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!vax135!whb
From: whb@vax135.UUCP
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: Time for 64-bit longs?
Message-ID: <1767@vax135.UUCP>
Date: Tue, 17-Feb-87 10:09:16 EST
Article-I.D.: vax135.1767
Posted: Tue Feb 17 10:09:16 1987
Date-Received: Wed, 18-Feb-87 04:15:46 EST
References: <4192@bu-cs.BU.EDU>
Reply-To: whb@vax135.UUCP (Wilson H. Bent)
Organization: AT&T Bell Labs, Holmdel, NJ
Lines: 30
Xref: watmath comp.lang.c:1061 comp.unix.wizards:993

In article <4192@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>(assume BITSnn is a derived nn-bit scalar type to avoid confusion)
>	struct pointer {
>		BITS32	NodeAddress;		/* address on network */
>		struct device {
>			BITS16	MajorDevice;	/* type of device */
>			BITS16	MinorDevice;	/* which of that type */
>		}
>		BITS64	Offset;			/* memory, seekptr etc */
>	};
>Nahh, 128-bits isn't enough cuz 32-bits isn't enough for the segmented
>network space...
>	-Barry Shein, Boston University

You're right, this sort of addressing would be useful TODAY, not just
later.  However...

This is not really a 128-bit pointer, this is a structure with many parts.
It is a perfect example of why I enjoy programming in C: the ability to
clump together various data types in one easy-to-use struct.

To deal with this as a 128-bit pointer would require bit shifting and
masking: lemme see, MajDev = (pointer >> 80) & 0xFFFF;
I'd rather stick with a structure that happens to be 128 bits long.

Which is not to say that I'm against 64-bit ints...
-- 
Wilson H. Bent, Jr.		... ihnp4!vax135!hoh-2!whb
AT&T - Bell Laboratories	(201) 949-1277
Disclaimer: My company has not authorized me to issue a disclaimer.