lm@cottage.UUCP (06/08/87)
Hi there. (sorry, pete). Suppose you were to bring up a Unix on a machine that liked 64 bit ints better than 32 bit ints. Would you be tempted to make some of the changes that have already been anticipated - such as making the time fields be 64 bits in things like the stat buf and timer structs? Or would you leave things alone so that old code worked? What other things would you consider given a Cray or something similar? Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy
daveb@geac.UUCP (Dave Brown) (06/09/87)
In article <3659@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes: >Hi there. (sorry, pete). Suppose you were to bring up a Unix on a machine >that liked 64 bit ints better than 32 bit ints. Would you be tempted to >make some of the changes that have already been anticipated - such as making >the time fields be 64 bits in things like the stat buf and timer structs? >Or would you leave things alone so that old code worked? Well, on 36-bit machines the advice of history is to make them 36... Primarily so that old code worked. Are you perhaps thinking of both 32 and 64-bit CPUs dealing with the same binaries? Normally increasing a word size makes little difference to C compilers & their support environments, its making them smaller that hurts (try to get AR and DR into a 32-bit word some time) --dave (clarification, svp) brown
francus@cheshire.columbia.edu.UUCP (06/10/87)
In article <743@geac.UUCP> daveb@geac.UUCP (Dave Brown) writes: >In article <3659@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes: >>Hi there. (sorry, pete). Suppose you were to bring up a Unix on a machine >>that liked 64 bit ints better than 32 bit ints. Would you be tempted to >>make some of the changes that have already been anticipated - such as making >>the time fields be 64 bits in things like the stat buf and timer structs? >>Or would you leave things alone so that old code worked? I seem to recall that when UTS first came out on the Amdahl they were using 64 bits per integer. Eventually they went back to 32 bits. If my recollection is correct you may want to find out why that decision was made. ****************************************************************** yoseff f In Xanadu did Kubla Khan a stately pleasure dome decree But only if the NFL to a franchise would agree.
len@elxsi.UUCP (06/11/87)
In article <4679@columbia.UUCP> francus@cheshire.columbia.edu.UUCP (Yoseff Francus) writes: >In article <743@geac.UUCP> daveb@geac.UUCP (Dave Brown) writes: >>In article <3659@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes: >>>Hi there. (sorry, pete). Suppose you were to bring up a Unix on a machine >>>that liked 64 bit ints better than 32 bit ints. Would you be tempted to >>>make some of the changes that have already been anticipated - such as making >>>the time fields be 64 bits in things like the stat buf and timer structs? >>>Or would you leave things alone so that old code worked? > >I seem to recall that when UTS first came out on the Amdahl they >were using 64 bits per integer. Eventually they went back to 32 >bits. If my recollection is correct you may want to find out > >why that decision was made. > >****************************************************************** >yoseff f >In Xanadu did Kubla Khan a stately pleasure dome decree >But only if the NFL to a franchise would agree. Deja vu! I seem to remember responding to a similar message some months ago, possibly in another newsgroup. ELXSI went through the same scenario during our development. We started out with 64-bit longs and 32-bit ints and 32-bit pointers. This was fine, for a while, until folks with third-party applications code came along. Seems that there is a LOT of code in rather large packages that runs on a lot of machines, all of which have pointers and longs of the same number of bits. We may all know that this assumption limits portability, and all machine architectures do not agree with that of the VAX, but try and justify your actions to a real, money-paying customer who is hurting due to the difficulty of porting a critical package. Of course, we changed. Nowadays int, long, and pointer all are 32-bits and there is a new, absolutely non-portable thingy called a long long which is 64-bits. Sigh. Such is the price of progress. Len
stevesu@copper.UUCP (06/14/87)
In article <420@elxsi.UUCP>, len@elxsi.UUCP (Len Mills) writes: > In article <4679@columbia.UUCP> francus@cheshire.columbia.edu.UUCP (Yoseff Francus) writes: > >In article <743@geac.UUCP> daveb@geac.UUCP (Dave Brown) writes: > > > >I seem to recall that when UTS first came out on the Amdahl they > >were using 64 bits per integer. Eventually they went back to 32 > >bits. > > ELXSI went through the same scenario during our development. We started > out with 64-bit longs and 32-bit ints and 32-bit pointers. This was fine, > for a while, until folks with third-party applications code came along. > > Seems that there is a LOT of code in rather large packages that runs on > a lot of machines, all of which have pointers and longs of the same number > of bits. ^^^^^ > > Of course, we changed. Nowadays int, long, and pointer all are 32-bits > and there is a new, absolutely non-portable thingy called a long long > which is 64-bits. Sigh. Wait a minute. I thought that the VAX-induced portability problems were those caused by assuming that ints and _l_o_n_gs (and time_t's, etc.) were the same size. Who said anything about pointers? A lot of people believe that K&R say that sizeof(pointer) == sizeof(int), whereas the true statement is that sizeof(pointer) <= sizeof(an integral type). Code that casts pointers to integers and back can therefore be made more portable (to machines with sizeof(int) < sizeof(pointer) <= sizeof(long)) by casting the pointers to longs. That shouldn't cause any problems, other than the possibility of wasting a bit of space and time on machines where sizeof(int) == sizeof(pointer) < sizeof(long). You don't have to look at 64-bit supercomputers to find one with this property--just consider the pdp11. Have the compounded mistakes and confusion really reached the point where paranoid people must make sizeof(int) == sizeof(long), thus throwing away a perfectly good and useful type? Steve Summit stevesu@copper.tek.com
gwyn@brl-smoke.UUCP (06/14/87)
In article <3659@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes: >Suppose you were to bring up a Unix on a machine >that liked 64 bit ints better than 32 bit ints. It's generally fairly easy to decide what sizes to make the data types. For example, an (int) must be competent to access any element of a large array, so if you contemplate supporting super-large arrays (which I think is pretty silly) then an (int) may have to be large. Since the default integer data type is (int), it is normally chosen to be of a size that doesn't require extra overhead (such as masking and shifting) to access. A word-addressible machine with 64-bit words should probably have 64-bit (long)s, UNLESS you anticpate files exceeding 2^64 bytes in length (in which case use 128-bit (long)s). It undoubtedly should have 64-bit (int)s. Unless there is an exceptionally good reason not to, its (short)s should be strictly smaller than its (int)s, perhaps half their size. The size you choose for (char) may be influenced by the decision X3J11 has yet to make on how to handle "multi-byte characters"; 8 bits is most useful as things now stand, but stay tuned. Don't be too concerned about code portability, because applications that "knew" that the word size was 32 bits will probably have to be fixed no matter what choices you make for a 64-bit machine, just as they have to be fixed when porting to 16-bit machines.
hedrick@topaz.rutgers.edu.UUCP (06/14/87)
Unfortunately in C (as most other languages) there is no distinction between how you describe variables to be used within your program and how you describe external objects. The result is that network code and code that handles records on tapes, etc., is full of descriptions that use char, short and long, to refer to 8, 16, and 32 bit quantities. Frankly I think this is a mistake. I think we should have a separate way of declaring external objects that is independent of the machine's byte order, word size, etc. But at the moment there isn't much choice. Those of us who write portable code have gotten used to the fact that you can't be sure of the size of int and pointers. But if we are to have any hope of writing portable network code, there has to be some way to say that something is a 16 or 32 bit object. Currently short and long are it. Anybody have a better idea? The only alternative I can think of is to use long:16 and long:32. Presumably that would continue to work if longs expanded. But I think most people would find this impossibly ugly.
blarson@castor.usc.edu.UUCP (06/14/87)
In article <1124@copper.TEK.COM> stevesu@copper.TEK.COM (Steve Summit) writes: >A lot of people believe that K&R say that >sizeof(pointer) == sizeof(int), whereas the true statement is >that sizeof(pointer) <= sizeof(an integral type). Nope. It says you can cast a pointer to an integral type and back without loosing [significant] information. Prime 64v mode C is correct and has 32 bit long (and int) and 48 bit pointers. Nothing is said about the relitive sizes. -- Bob Larson Arpa: Blarson@Usc-Ecl.Arpa Uucp: {sdcrdcf,seismo!cit-vax}!usc-oberon!castor!blarson "How well do we use our freedom to choose the illusions we create?" -- Timbuk3
jerry@oliveb.UUCP (07/08/87)
In article <12670@topaz.rutgers.edu> hedrick@topaz.rutgers.edu (Charles Hedrick) writes: >Unfortunately in C (as most other languages) there is no distinction >between how you describe variables to be used within your program and >how you describe external objects. The result is that network code >and code that handles records on tapes, etc., is full of descriptions >that use char, short and long, to refer to 8, 16, and 32 bit >quantities. Frankly I think this is a mistake. I think we should >have a separate way of declaring external objects that is independent >of the machine's byte order, word size, etc. But at the moment there The inability to precisly specify type sizes is a bad limitation of C. As a practacal work around some code will either define or typedef int16 and int32 values in an include file. These can be used thruout the program and only the include file needs to be changed when porting. This is a common enough problem that all versions of unix should have a standard include file that defines the various size values more precisely. Also nice would be the ability to specify at least N bits but round up to the next largest size. I am not a fan of Pascal but it does handle this a little better than C. Jerry Aguirre
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (07/10/87)
In article <1893@oliveb.UUCP> jerry@oliveb.UUCP (Jerry F Aguirre) writes: >In article <12670@topaz.rutgers.edu> hedrick@topaz.rutgers.edu (Charles Hedrick) writes: >>... >... >The inability to precisly specify type sizes is a bad limitation of C. >As a practacal work around some code will either define or typedef >int16 and int32 values in an include file. These can be used thruout >the program and only the include file needs to be changed when porting. When this was discussed by X3J11, I suggested a syntax like fortran, "int*2" or "float*4" where the MINIMUM size of the variable was specified. This was "not in the spirit of C" or something. I agree it's ugly, but maybe in C 91 we can address this problem. -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me