rcd@ico.isc.com (Dick Dunn) (02/13/90)
I've changed my mind a few times on this, but I think we're likely to see
64-bit addresses (or, at the least, larger-than-32-bit addresses) a while
before we see 64-bit integers. Reasoning: I see more machines pushing
toward a gigabyte of storage, and if you're putting that much physical
memory on a machine, surely you can create processes with virtual>real.
But 64-bit integer operations, particularly multiply/divide, are still sort
of expensive...too expensive to justify the limited return. 32 bits is a
big number.
If this 64/32 split happens, it's not going to be a happy situation, as
anyone who's ever fought a 286 in large muddle will realize. Having a
pointer larger than an integer breaks LOTS of C code. To be sure, the code
usually breaks because it's poorly written, but it may still be heavily
used. Any program that doesn't get lint-ed regularly is likely to be
broken, especially if it uses linked structures. Yacc grammars are a
complete disaster.
--
Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...Mr. Natural says, "Use the right tool for the job."daf00@uts.amdahl.com (Dana Freiburger) (02/13/90)
Instead of 64 bit addressing, the ESA/370 architecture uses the advanced address-space facility to provide multiple address spaces 2G-byte in size. In effect, many 2G-byte spaces (31 bit addressing) versus one single giant address space (32+ bit addressing). I don't think IBM was worried about C programs when they designed ESA/370; IBM needed to provide a way for a program to have access to a larger concurrent address space than 370-XA allowed but with a level of compatibility with 370-XA. In this case, it's programs defining the architecture, not the architecture defining the programs.
peter@ficc.uu.net (Peter da Silva) (02/14/90)
In article <1990Feb12.182411.5982@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes that he expects 64-bit pointers before 64-bit integers... > But 64-bit integer operations, particularly multiply/divide, are still sort > of expensive...too expensive to justify the limited return. 32 bits is a > big number. On the other hand, there are chips extant for which 32-bit integer multiply and divide are considered too expensive to put into silicon. I can see a machine with 64-bit registers but only 32x32=64 multiplies without straining. You'd probably have 32-bit ints and 64-bit long ints. As you say... > If this 64/32 split happens, it's not going to be a happy situation... -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/14/90)
In article <1990Feb12.182411.5982@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: | If this 64/32 split happens, it's not going to be a happy situation, as | anyone who's ever fought a 286 in large muddle will realize. Having a | pointer larger than an integer breaks LOTS of C code. I think that most of the vendors realize this, although if anyone ever makes a large model compiler for the 386 it will have the same problem. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me
pkr@maddog.sgi.com (Phil Ronzone) (02/14/90)
In article <1990Feb12.182411.5982@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >I've changed my mind a few times on this, but I think we're likely to see >64-bit addresses (or, at the least, larger-than-32-bit addresses) a while >before we see 64-bit integers. Reasoning: I see more machines pushing >toward a gigabyte of storage, and if you're putting that much physical >memory on a machine, surely you can create processes with virtual>real. >But 64-bit integer operations, particularly multiply/divide, are still sort >of expensive...too expensive to justify the limited return. 32 bits is a >big number. Key Computer, now owned by Amdahl, is working on a huge scalar UNIX machine. It has 64-bit addresses and 64-bit ints. Just think of the fun they'll have with 32-bit shorts. ------Me and my dyslexic keyboard---------------------------------------------- Phil Ronzone Manager Secure UNIX pkr@sgi.COM {decwrl,sun}!sgi!pkr Silicon Graphics, Inc. "I never vote, it only encourages 'em ..." -----In honor of Minas, no spell checker was run on this posting---------------