Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!uc!shamash!hare!jjn From: jjn@hare.cdc.com (jj needham 234-4312) Newsgroups: comp.arch Subject: 64 bits (long winded editorial) Message-ID: <25414@shamash.cdc.com> Date: 5 Sep 90 06:55:42 GMT References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <1990Aug31.174957.9612@cimage.com> <3656@goanna.cs.rmit.oz.au> <1990Sep2.220249.19420@cimage.com> <1381@svin02.info.win.tue.nl> <18286@ultima.socs.uts.edu.au> Sender: news@shamash.cdc.com Reply-To: jjn@hare.udev.cdc.COM (jj needham 234-4312) Organization: CDC - Santa Clara Lines: 67 In article <18286@ultima.socs.uts.edu.au> jeremy@sinope.socs.uts.edu.au (Jeremy Fitzhardinge) writes: >rcpieter@svin02.info.win.tue.nl (Tiggr) writes: > >>>Does anyone seriously believe that a sane computer vendor will create >>>a new flavor of hardware in the nineties, with no evidence of any >>>customers? >> >>Who claims there is no evidence of customers? And if there are >>customers, somebody will jump in the market with something to suit >>there needs. I wouldn't mind to have a nice machine with 64bit >>registers, databus and addressbus, where the addressbus adresses >>bits, and not bytes, giving 2^64 BITS of memory. What I don't >>really like is thinking about alignment restrictions... > > >The C compiler I use on it is a subset of C that doesn't take full advantage I may have missed too much of this conversation over the past week or so but was surprised no CDC people have commented. I exclude Rob Peglar and company as the Cyber 200/ETA is different from the Cyber 180. CDC has lived with a full 64 bit architecture all through the eighties. Cyber 180 architecture addressed many problems that 170 (and to a lesser degree early Cray stuff) lacked. Security, memory and 8 bit bytes. 16 rings of hardware support in addressing with locks and keys thrown in. 48 bit virtual address. (32bits/segment-12 bits worth of segments-4 bits of hardware). Not exactly your garden variety PDP-11 clone. Try using the same media (50K gate CMOS or whatever) as your competitors who only have to implement 32 bits worth of CPU. Half your expendable chip real estate is gone. I have spent time working on both a C compiler and ported Unix applications to Cyber 180 series. This was very frustating as you try and compete with Vaxes and such. Pointers are clearly incompatible with any idea of an _int_. The CPU by design contains both address registers are not data registers. 6000, 170, 180 and Crays have A,X (sometimes B,V) register sets and you have to constantly move pointers back and forth between address and data registers to get the code to work. This may not be a problem in other 64 bit systems, but how many are commercially available? One thing CDC does not have, competition in the 64-bit production OS market. Don't even mention porting something like Oracle. Oracle Corp. informs us that we are one of the few companies to sucessfully port PL#SQL to a non-32 bit architecture. The Oracle kernel wasn't much easier. In trying to improve both a C compiler and a C application I have found that the 64 bit register file is best left to an accelorator. Like the man said, who needs it? CDC almost died trying to answer that question. If it don't look like a PDP-11, your doomed, man! People who need 64-bits don't need it to run _egrep_. They it need for a specific numeric purpose. Having a 64-bit floating point unit as part of a 32 bit scalar implementation seems to be a good comprimise. I guess everybody always needs more address bits. Well that ought to stir up some dust ... jeff Disclaimer: | Jeff Needham If you become any more forgetful, you | Oracle Performance Group will be qualified enough to work in | Control Data - Santa Clara, CA Performance Analysis! | INTERNET jjn@hare.udev.cdc.com