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