Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: R4000 "announcement" (64-bit stuff) Message-ID: <46045@mips.mips.COM> Date: 20 Feb 91 21:32:51 GMT References: <90@shasta.Stanford.EDU> <1991Feb8.055009.9883@ico.isc.com> <45789@mips.mips.COM> <91206@lll-winken.LLNL.GOV> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 69 In article <91206@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: >| From: mash@mips.COM (John Mashey) >| At one point in time, C and UNIX really KNEW that an int, and a pointer >| were 16-bits long. Then, C got "long", to at least do 32-bit >| calculations, and "int" became whatever was convenient. Inside Bell >| Labs, before UNIX got ported to other machines, C at least was available >| on various 32-bit architectures (like S/360). >| As UNIX got ported to other 32-bit machines, all of us bad people who'd >| figured int & char * were the same thing suffered, but everybody learned >| pretty quickly not to assume this, and how to write code that would work >| both on the 32-bitters (for future) and for 16-bitters (for installed >| base). ... > I hate to disappoint you John, but the current installed code base is >*VERY* sloppy about short vs. int vs. long vs. char * vs. ... When we >ported 4.3BSD to the PDP-11 one of the biggest problems was the >assumption that int == long in the BSD code. I corrected literally >thousands of such errors. > I don't think that the next move will be any easier. Nor do I think >such a move will ever be easy until we throw away lint, an abomination >that should never have existed, and install its functions into the >compiler itself so programmers can never escape it. This won't solve all >of our problems, but it will go a long way. At least many modern >compilers are much more picky about what they'll accept. The old V6 >compiler would let you do: > int i, j; > i = j.foo; >Where foo is a field member of some structure. Absolutely incredible. >And the V6 kernel was full of such coding. I don't think we actually disagree, if you read carefully. 1) V6 was PDP-11-based, all of the way. 2) V7 had at least addressed the 16->32-bit issue, and also a byte-order switch. 3) As it happens, most of this stuff REALLY got addressed, in practice, at numerous places inside Bell Labs, as people had to get code that ran on {PDP-11, VAX, 3B20, 3B2}. Note that portability was a general goal of V7 (research), and was pretty well-handled. However, it was a more detailed, grind-it-out practice of the various development groups at BTL, who had much more pressing concerns of forward & backward compatibility, because they HAD to support older machines in massive numbers in the field, something that was (rightfully) not a necessary goal for Research. Put another way: outside the Labs, you didn't necesarily see the code where a lot of this attention was placed. Anyway, my claim is: for a while, in late 70s, there were a fairly large number of people with immediate experience with making code portable across machines with different-sized pointers. I also claim, and in fact, one of the reasons for talking about the 64-bit stuff is: a) the prevalence of 32-bit machines has probably caused us to get sloppier than we were for a while. In some sense, we may be partially "saved" by the existence of code for both 286 & 386 :-) b) Hence, some people may need a poke now, to allow time to get careful again. c) However, there are at least people in existence who do recall this (outside of the 286->386 domain), and many application developers doing new code are a lot cleaner about this stuff. 1991 is NOT 1980, even thought sloppiness does remain. MANY more developers are much more aware of portability issues than in 1980, where it was OK if it ran on a VAX. -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086