bcase@cup.portal.com (Brian bcase Case) (04/06/89)
>Take a look at this month's Spectrum -- there's an article about the >Intel i680 chip, which seems to have a flat 64-bit address space. No, it has a 64-bit data bus and a 32-bit address bus; the address space is a flat, 4Gbyte space. This is why I don't think it should be called a 64-bit microprocessor.
Tim_CDC_Roberts@cup.portal.com (04/06/89)
In <16568@winchester.mips.COM>, mash@mips.COM (John Mashey) asks: > One interesting issue, for some ways out, is what the 64-bit model ought > to be be: maybe some of the mini-super and supercomputer folks can give us > some hints here: > What's the C programming model for machines with 64-bit pointers? > how do you say 8-, 16-, 32, and 64-bit ints? > (char and short are fine. Now, are 64s long-longs, > or just longs? are 32s longs? which one is int? In the Control Data Cyber 180 NOS/VE C compiler, you have the following: char 8 bits short 32 bits int 64 bits long 64 bits float 64 bits double 128 bits Note that this agrees with the underlying hardware; it does not make sense to have a 16-bit int type, because the machine doesn't do any native 16 bit arithmetic. I should have looked it up, but I didn't; addresses on the Cyber 180 are 48 bits, so I would assume that "sizeof(*int)" is 6. Of course, you could always: struct ugly { short sixteen : 16; }; But what's the point? Tim_CDC_Roberts@cup.portal.com | Control Data... ...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.
norvell@csri.toronto.edu (Theodore Stevens Norvell) (04/08/89)
In article <16716@cup.portal.com> Tim_CDC_Roberts@cup.portal.com writes: >In <16568@winchester.mips.COM>, mash@mips.COM (John Mashey) asks: > >> One interesting issue, for some ways out, is what the 64-bit model ought >> to be be: maybe some of the mini-super and supercomputer folks can give us >> some hints here: >In the Control Data Cyber 180 NOS/VE C compiler, you have the following: > > char 8 bits > short 32 bits > int 64 bits > long 64 bits > float 64 bits > double 128 bits [See correction below] > >Note that this agrees with the underlying hardware; it does not make sense >to have a 16-bit int type, because the machine doesn't do any native 16 bit >arithmetic. > >I should have looked it up, but I didn't; addresses on the Cyber 180 are >48 bits, so I would assume that "sizeof(*int)" is 6. > Not a bad assumption, but had Tim looked it up he would have found that: pointer to data 64 bits pointer to function 64 bits This decision was made to support programs that assume pointers and integers are the same size. I don't know if it was the right decision or not. Note also that double is 64 bits not 128 as Tim said. This is because argument passing and floating calculation are done in double in C. I hope Tim isn't writing any programs that rely on 128 bit doubles :-) The forthcoming ANSI C compiler will provide long double which will almost certainly be 128 bits. Since C on the Cyber 180 was brought up, let me mention that a brand new (i.e. we haven't got a lot of the bugs out yet) C compiler will soon be out. It will provide far better compilation rates (up to 5x) and somewhat better object code. It will be better integrated with the NOS/VE programming environment too (which is not to say it will be totally unusable from Unix). Cyber 180 is a line of computers from small mainframes to almost supercomputers. It should not be confused with the Cyber 170 (also NOS/VE is not NOS). 180's have byte addressing and large virtual address spaces (8 gigabytes). The above should in no way be interpreted as a statement belonging to or comming from my employer. I'm a compiler writer, not a spokesperson. (They already fired me; I'd rather they didn't sue me too.) Theodore Norvell of (what's left of) Control Data Canada
norvell@csri.toronto.edu (Theodore Stevens Norvell) (04/11/89)
In article <8904072220.AA03632@yorkmills.csri.toronto.edu> norvell@csri.toronto.edu (Theodore Stevens Norvell) writes: >Cyber 180's have byte addressing and large virtual address spaces (8 gigabytes) What I meant was 8 TERRAbytes (2 to the 43 bytes) per process. Theodore Norvell (Thanks to Mark Chojnacki for pointing this out.)