[comp.lang.c] Time for 64-bit longs?

jbuck@epimass.UUCP (01/28/87)

DEC announced the SA482 disk subsystem, which stores 2.5 gigabytes
of data.  System Industries plans a drive that stores 4 G.  But
the maximum value a 32-bit signed value can store is about 2.1E9.
Without a data type longer than 32 bits, you can't deal with files
or partitions bigger than this.

Has anyone bit the bullet and gone to 64-bit longs?  I know Convex
has a monstrosity called a "long long" that's 64 bits; they leave
long as 32 bits, the same as int, apparently because it was too hard
to change all the Berkeley code that assumes long == int.  But it
seems the Vax architecture will soon require a 64-bit type at the
high end.

-- 
- Joe Buck 	{hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck	HASA (A,S)
  Entropic Processing, Inc., Cupertino, California

guy@gorodish.UUCP (01/29/87)

>they leave long as 32 bits, the same as int, apparently because it was
>too hard to change all the Berkeley code that assumes long == int.

I suspect there is a lot of NON-Berkeley code that makes the
assumption that "long" is 4 bytes, 32 bits, or whatever.
Unfortunately, C lacks a general way to ask for data that are some
particular size, however you choose to define this size; you can't
ask for subranges, and the only way you can ask for some specific
number of bits is to ask for a bit field - but bit fields are not
first-class citizens.

>But it seems the Vax architecture will soon require a 64-bit type at the
>high end.

The VAX architecture already has some support for "quad"s, although
there may not be as many instructions that support them as there are
instructions to support shorter types (although this may not be
necessary if the use of "quad"s would mostly be limited to dealing
with addresses in huge files).

However, I think the chances are pretty slim that this type would
replace "long"s, either in the sense of "long"s in C or "long"s in
the VAX architecture.  If it appears, the chances are very good that
it will appear in VAX C implementations as "long long int" or
something like it.

ed@mtxinu.UUCP (01/29/87)

>Has anyone bit the bullet and gone to 64-bit longs?  I know Convex
>has a monstrosity called a "long long" that's 64 bits; they leave
>long as 32 bits, the same as int, apparently because it was too hard
>to change all the Berkeley code that assumes long == int.  But it
>seems the Vax architecture will soon require a 64-bit type at the
>high end.

The problem is not that the VAX code assumes int == long (it often
does make that assumption, but those are bugs) but that C defines
only two sizes of integer: long and short.  Int may be either,
depending on the implementation, but it must be one or the other.

Other people have used the "long long" hack, too.

-- 
Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
{ucbvax,decvax}!mtxinu!ed   +1 415 644 0146

"A man of quality is not threatened by a woman of equality."

jsm@vax1.UUCP (01/30/87)

In article <848@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes:
>Has anyone bit the bullet and gone to 64-bit longs?  I know Convex
>has a monstrosity called a "long long" that's 64 bits; they leave
>long as 32 bits, the same as int, apparently because it was too hard
>to change all the Berkeley code that assumes long == int.  But it
>seems the Vax architecture will soon require a 64-bit type at the
>high end.

And will the future 128-byte pointer be a "long long long" ? 

news@cit-vax.UUCP (01/30/87)

Organization : California Institute of Technology
Keywords: 
From: jon@oddhack.Caltech.Edu (Jon Leech)
Path: oddhack!jon

In article <291@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes:
>The problem is not that the VAX code assumes int == long (it often
>does make that assumption, but those are bugs) but that C defines
>only two sizes of integer: long and short.  Int may be either,
>depending on the implementation, but it must be one or the other.

	I don't think this is correct. All K&R says about it is
that 'short is no longer than long' (pg 34 sec 2.2). Why not have
short=16 bits, int=32 bits, long=64 bits?

    -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon)
    Caltech Computer Science Graphics Group
    __@/

smv@necis.UUCP (01/30/87)

As long as you're going to go hacking up the C language definitions, why not
introduce a new keyword "very" as in a "very long" (or even a "very short").
This has the advantage that when compiling code for a machine which has no
very long type, you can simply #define very /**/ and forget it.  With long long
you can't do this as easily.

I know that adding any new keywords will cause other problems, but after all,
this topic involves biting bullets of some sort anyway you look at it.

-- 
Steve Valentine, NEC Information Systems 289 Great Rd., Acton, MA 01720
smv@necis.nec.com

SofPasuk@imagen.UUCP (01/30/87)

In article <1643@cit-vax.Caltech.Edu>, news@cit-vax.Caltech.Edu (Usenet netnews) writes:
> ... Why not have
> short=16 bits, int=32 bits, long=64 bits?
> 

It would have been nice perhaps if the language was originally defined that
way.  But a retrofit that would make long=64 bits would play real havoc
with not only portability issues (no flames please, I'm talking REALITY here),
but also with execution performance of programs that need no more than 32-bit
precision, use long for same, and now have to use 64 bit arithmetic (possibly
invoking run time routines for every arithmetic operation).

guy@gorodish.UUCP (01/30/87)

>And will the future 128-byte pointer be a "long long long" ? 

Absolutely NOT.  A "long long long (int)" will be an integral type;
pointer types are not the same as integral types.

ballou@brahms.Berkeley.EDU.UUCP (01/31/87)

In article <291@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes:
>The problem is not that the VAX code assumes int == long (it often
>does make that assumption, but those are bugs) but that C defines
>only two sizes of integer: long and short.  Int may be either,
>depending on the implementation, but it must be one or the other.

	WRONG!

	K&R, pp. 182-3:

		Up to three sizes of integer, declared short int,
	int, and long int, are available.  Longer integers provide
	no less storage than shorter ones, but the implementation
	may make either short integers, or long integers, or both
	be equivalent to plain integers.

I don't see anything there that requires int be the same size as one of
short and long.

--------
Kenneth R. Ballou			ARPA:  ballou@brahms.berkeley.edu
Department of Mathematics		UUCP:  ...!ucbvax!brahms!ballou
University of California
Berkeley, California  94720

jas@rtech.UUCP (01/31/87)

> ... C defines
> only two sizes of integer: long and short.  Int may be either,
> depending on the implementation, but it must be one or the other.
> 
> Other people have used the "long long" hack, too.
> 
> -- 
> Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
> {ucbvax,decvax}!mtxinu!ed   +1 415 644 0146

"Up to three sizes of integer, declared short int, int, and long int,
available.  Longer integers provide no less storage than shorter ones,
but the implementation MAY [my emphasis] make either short integers,
long integers, or both, equivalent to plain integers."

K&R, pp. 182-3.
-- 
Jim Shankland
 ..!ihnp4!cpsc6a!\
                  rtech!jas
..!ucbvax!mtxinu!/

jbuck@epimass.UUCP (01/31/87)

In article <291@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes:
>The problem is not that the VAX code assumes int == long (it often
>does make that assumption, but those are bugs) but that C defines
>only two sizes of integer: long and short.  Int may be either,
>depending on the implementation, but it must be one or the other.

Please quote chapter and verse of K&R or the ANSI draft standard.
I don't recall seeing this anywhere.  K&R only guarantees

	sizeof (short) <= sizeof (int) <= sizeof (long)

-- 
- Joe Buck 	{hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck	HASA (A,S)
  Entropic Processing, Inc., Cupertino, California

jtr485@umich.UUCP (02/01/87)

In article <291@mtxinu.UUCP>, ed@mtxinu.UUCP writes:
> >Has anyone bit the bullet and gone to 64-bit longs?
> The problem is not that the VAX code assumes int == long (it often
> does make that assumption, but those are bugs) but that C defines
> only two sizes of integer: long and short.  Int may be either,
> depending on the implementation, but it must be one or the other.
NO!  Int does not have to be short or long.  It just has to be at least
as large as short and at least as small as long.  So you can have
8 bit short; 16 bit int; 32 bit long	/* some 68000 C compilers have this */
or
16 bit short; 32 bit int; 64 bit long	/* reasonable for a vax */
> Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA

jtr485@umich.UUCP (02/01/87)

In article <260@vax1.ccs.cornell.edu>, jsm@vax1.UUCP writes:
> In article <848@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes:
> >Has anyone bit the bullet and gone to 64-bit longs?  I know Convex
> >has a monstrosity called a "long long" that's 64 bits; they leave
> >long as 32 bits, the same as int, apparently because it was too hard
> >to change all the Berkeley code that assumes long == int.  But it
> >seems the Vax architecture will soon require a 64-bit type at the
> >high end.
> And will the future 128-byte pointer be a "long long long" ? 

Even assuming you meant 128-bit address,just what do you propose doing with
that pointer?  Going to assign every quark in the universe its own address?

--j.a.tainter

pjc@pbhye.UUCP (02/02/87)

In article <12441@sun.uucp> guy@sun.UUCP (Guy Harris) writes:
>>And will the future 128-byte pointer be a "long long long" ? 

main ()
{
	reallybig	i;
}

tps@sdchem.UUCP (02/03/87)

In article <291@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes:
>>Has anyone bit the bullet and gone to 64-bit longs?  I know Convex
>>has a monstrosity called a "long long" that's 64 bits; they leave
>>long as 32 bits, the same as int, apparently because it was too hard
>>to change all the Berkeley code that assumes long == int.  But it
>>seems the Vax architecture will soon require a 64-bit type at the
>>high end.
>
>The problem is not that the VAX code assumes int == long (it often
>does make that assumption, but those are bugs) but that C defines
>only two sizes of integer: long and short.  Int may be either,
>depending on the implementation, but it must be one or the other.
>Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA

Wrong.
(Perhaps this is an example of "if I've never seen anybody do it, I guess
there must be a law against it"?:)

K&R p. 34

	"...each compiler is free to interpret 'short' and 'long' as
	appropriate for its own hardware.
	...all you should count on is that 'short' is no longer than 'long'"












|| Tom Stockfisch, UCSD Chemistry	tps%chem@sdcsvax.UCSD

brian@ncroem.UUCP (02/04/87)

Someone had pointed out that they had never seen a case where ints were neither
short nor long.  On Alcor C, for the TRS-80 Model 4, shorts are 1 byte, ints 2,
and longs 4.

rmtodd@uokmax.UUCP (02/07/87)

In article <629@sdchema.sdchem.UUCP>, tps@sdchem.UUCP (Tom Stockfisch) writes:
> In article <291@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes:
> >does make that assumption, but those are bugs) but that C defines
> >only two sizes of integer: long and short.  Int may be either,
> >depending on the implementation, but it must be one or the other.
> Wrong.
> (Perhaps this is an example of "if I've never seen anybody do it, I guess
> there must be a law against it"?:)
> K&R p. 34
> 	"...each compiler is free to interpret 'short' and 'long' as
> 	appropriate for its own hardware.
> 	...all you should count on is that 'short' is no longer than 'long'"
Actually, I know of a compiler on which short, int, and long all have
different sizes.  On Alcor C on my TRS-80 Model I, short is 8 bits, int is
16 bits, and long 32 bits.  So yes, somebody out there does it.
(Granted, Alcor's C will never win any awards for portability because of its
library, but it's still a full C compiler.)
(Model I -- how's that for esoteric hardware? :-)
___________________________________________________________________________
Richard Todd
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd

guy@gorodish.UUCP (02/09/87)

>Even assuming you meant 128-bit address,just what do you propose doing with
>that pointer?

Supporting large sparse address spaces, presumably; there are plenty
of reasons for wanting to do that.

phil@amdcad.UUCP (02/09/87)

In article <848@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes:
>DEC announced the SA482 disk subsystem, which stores 2.5 gigabytes
>of data.  System Industries plans a drive that stores 4 G.  But
>the maximum value a 32-bit signed value can store is about 2.1E9.
>Without a data type longer than 32 bits, you can't deal with files
>or partitions bigger than this.

Ah, the SA482 is a cabinet containing four "RA-82"s, each holding
about 600 Mbytes. Assuming Unix continues to treat each drive as
separate, 32 bits should be plenty to address the data on each drive.
I'm not familiar with the SI product but imagine it too is a
collection of drives, not a single drive. 

The "RA-82" is not available separately and DEC has not announced any
plans to market it that way. DEC has said the technology is on its
last legs and any future products will use fancy stuff like thin film
heads and plated media. Of course, they've been known to change their
minds before.

I wonder when DEC is going to release their "Sun-killer".
-- 
 They also surf who only stand on waves.

 Phil Ngai +1 408 982 7840
 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com

wong@rtech.UUCP (02/09/87)

We, here at Relational Technology, have seen machines with

	long = 64 bits
	int  = 32 bits
	short = 16 bits

or, even worse,

	long = 64 bits
	int = 32 bits
	short = 32 bits!

As you might expect, this causes all sorts of problems in trying to
port code.  Seems like programmers pretty much assume "normal" (read
Vax) sizes for integers when writing code.

-- 
				J. Wong		ucbvax!mtxinu!rtech!wong

****************************************************************
You start a conversation, you can't even finish it.
You're talking alot, but you're not saying anything.
When I have nothing to say, my lips are sealed.
Say something once, why say it again.		- David Byrne

sherm@elxsi.UUCP (02/10/87)

In article <1643@cit-vax.Caltech.Edu> jon@oddhack.UUCP (Jon Leech) writes:
>	I don't think this is correct. All K&R says about it is
>that 'short is no longer than long' (pg 34 sec 2.2). Why not have
>short=16 bits, int=32 bits, long=64 bits?
>
>    -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon)
>    Caltech Computer Science Graphics Group

When we began our first Unix port to the ELXSI we tried your suggestion
and found that it was actually *rare* to find a program that would still
work with 64-bit longs.  

After repeatedly bashing our heads against horrible debugging problems in 
third-party's 100,000 line applications we finally saw the light and 
switched to a 32-bit long and a 64-bit long long.

Moral arguments aside, we're stuck with int==long.
-- 
-------------------------------------------------------------------------------
Michael Sherman
...!{sun|styx}!elxsi!sherm

news@cit-vax.UUCP (02/10/87)

Organization : California Institute of Technology
Keywords: 
From: jon@oddhack.Caltech.Edu (Jon Leech)
Path: oddhack!jon

In article <263@elxsi.UUCP> sherm@elxsi.UUCP (Michael Sherman) writes:
>In article <1643@cit-vax.Caltech.Edu> I write:
>>Why not have
>>short=16 bits, int=32 bits, long=64 bits?
>
>When we began our first Unix port to the ELXSI we tried your suggestion
>and found that it was actually *rare* to find a program that would still
>work with 64-bit longs.  

	I remember that. All of MY programs worked ok :-)

>
>After repeatedly bashing our heads against horrible debugging problems in 
>third-party's 100,000 line applications we finally saw the light and 
>switched to a 32-bit long and a 64-bit long long.
>
>Moral arguments aside, we're stuck with int==long.

	Moral arguments aside, int != long on most 80x86 and some 68000
implementations. I think what you're really stuck with is long == 32 bits.

    -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon)
    Caltech Computer Science Graphics Group
    __@/

henry@utzoo.UUCP (Henry Spencer) (02/10/87)

> The "RA-82" is not available separately and DEC has not announced any
> plans to market it that way...

DEC just wants you to buy the package deal rather than waiting to buy only
as many drives as you need.  Scuttlebutt has it that the RA82 will be
available this summer.

> DEC has said the technology is on its
> last legs and any future products will use fancy stuff like thin film
> heads and plated media...

A cynical man would say that the RA disk technology has been on its last
legs ever since it was announced!  One rumor is that the SA482/RA82
announcement has been repeatedly postponed because all available supplies
of HDAs were going to Field Service as replacements for failing RA81 HDAs.
-- 
Legalize			Henry Spencer @ U of Toronto Zoology
freedom!			{allegra,ihnp4,decvax,pyramid}!utzoo!henry

mouse@mcgill-vision.UUCP (02/11/87)

In article <66@umich.UUCP>, jtr485@umich.UUCP (Johnathan Tainter) writes:
> In article <260@vax1.ccs.cornell.edu>, jsm@vax1.UUCP writes:
>> In article <848@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes:
>>> Has anyone bit the bullet and gone to 64-bit longs?
>> And will the future 128-byte pointer be a "long long long" ?
> Even assuming you meant 128-bit address,just what do you propose
> doing with that pointer?  Going to assign every quark in the universe
> its own address?

Just because the poor guy slipped up and wrote "pointer", don't come
down too hard.  I would certainly like a C compiler which used
short=16, int=32, long=64.  Eventually, on a 64-bit machine, short=32,
int=64, long=128.

2^128 ~= 1.7E38, surely there are more than 2E38 quarks.

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu

tanner@hropus.UUCP (02/12/87)

) sherm@elxsi.UUCP (Michael Sherman) writes
) [ ... ] Moral arguments aside, we're stuck with int==long.

This silly assumption is what makes it so hard to port code written
on a vax or 68K to a 16-bit machine.

I (working on a 16-bit machine) won't grant you that we're stuck with
int==long.

bzs@bu-cs.UUCP (02/14/87)

>Even assuming you meant 128-bit address,just what do you propose doing with
>that pointer?  Going to assign every quark in the universe its own address?
>
>--j.a.tainter

Being as this type of thing comes up so often consider a machine who's
HARDWARE supports the following virtual address space:

(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 */
	};

and assume a hardware instruction set that really could utilize such
pointers to address any disk, tape, memory etc on a large network.

Nahh, 128-bits isn't enough cuz 32-bits isn't enough for the segmented
network space...

Is that really too wild? I don't think so.

	-Barry Shein, Boston University

whb@vax135.UUCP (02/17/87)

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.

michael@crlt.UUCP (02/22/87)

[Nybbling away...]

In article <848@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes:
>Has anyone bit the bullet and gone to 64-bit longs?  I know Convex
>has a monstrosity called a "long long" that's 64 bits; they leave
>long as 32 bits, the same as int, apparently because it was too hard
>to change all the Berkeley code that assumes long == int.  But it
>seems the Vax architecture will soon require a 64-bit type at the
>high end.

On the side issue of naming them, how about "longer"s (for 64 or so),
"longeryet"s (for 128) and "longest"s (guaranteed to be the largest
you've got)?  This just adds new types, rather than a new syntax, to
the language.

(One would like "long" to keep its original meaning as "longest integer",
but that would expand the data segments of many existing programs.)

===========================================================================
  "I've got code in my node."	| UUCP:  ...!ihnp4!itivax!node!michael
				| AUDIO: (313) 973-8787
	Michael McClary		| SNAIL: 2091 Chalmers, Ann Arbor MI 48104
---------------------------------------------------------------------------
Above opinions are the official position of McClary Associates.  Customers
may have opinions of their own, which are given all the attention paid for.
===========================================================================