Xref: utzoo comp.arch:9163 comp.lang.c:17460
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!accuvax.nwu.edu!tank!ncar!unmvax!pprg.unm.edu!hc!lll-winken!uunet!portal!cup.portal.com!Tim_CDC_Roberts
From: Tim_CDC_Roberts@cup.portal.com
Newsgroups: comp.arch,comp.lang.c
Subject: Re: looking for >32-bit address space [and how will C handle it
Message-ID: <16716@cup.portal.com>
Date: 5 Apr 89 19:52:27 GMT
References: <1032@myrias.UUCP> <12289@reed.UUCP> <16568@winchester.mips.COM>
Distribution: na
Organization: The Portal System (TM)
Lines: 35

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.