Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers) Message-ID: <3310@crdos1.crd.ge.COM> Date: 3 Apr 91 16:28:38 GMT References: <1991Mar27.172325.10800@sj.nec.com> <7920@uceng.UC.EDU> <3305@crdos1.crd.ge.COM> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 43 In article peter@ficc.ferranti.com (Peter da Silva) writes: | In article <3305@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: | | > And the problems we've had porting between 32 and 64 bit computers | > didn't happen? | | You mean between 16 and 32 bit computers? No, it's not a big problem. Not unless someone just added PC emulation to the Cray2... lots of net code assumes 32 bits, assumes int {same as} long, assumes 2's complement arithmetic, and assumes you can get exactly four chars in an int. I stand by my first thought: the problem is in code which assumes things about the hardware. Language have variables of known minimum size, integer*4 in FORTRAN, long in C, etc. And languages which have pointers have portable ways to manipulate them, although you wouldn't know it from code posted from time to time. I have seen code which turned the address of a long into int, added seven, then cast it to pointer to char to get a byte out of the next word. Other than assuming the size of int, size of pointer, and byte order of the hardware, this was portable. If you say the "memory models" are a bad idea I would agree completely, and I told Microsoft so when they were writing C 3.0. Intel should have paid them to generate a version with 32 bit ints and linear addressing (from the user viewpoint) just to sell faster chips. But that's a feature of the design decisions of the C compiler, not an inherent feature of segments or Intel. Ask the person who ported unzip to the Cray about 32 vs. 64 problems. I don't remember what it was now, I looked at the problem for an hour or two and dropped it, but it was reasonably subtle, and I believe it's a warning of things to come. Perhaps MIPS will speak on porting stuff to their 64 bit box for testing. It's possible to do tricky stuff in a portable way, and if you think about it when writing the code it's even easy. When you try to port someone else's code it gets to be a nightmare. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"