home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.arch
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!ubc-cs!mprgate.mpr.ca!mcvey
- From: mcvey@mpr.ca (Iain McVey)
- Subject: Re: 32 => 64 Transition
- Message-ID: <1992Aug13.182851.18305@mprgate.mpr.ca>
- Sender: news@mprgate.mpr.ca
- Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
- References: <1992Aug08.165832.114442@cs.cmu.edu> <1992Aug11.125326.16719@email.tuwien.ac.at> <id.UHAS.9TA@ferranti.com>
- Date: Thu, 13 Aug 92 18:28:51 GMT
- Lines: 37
-
- In article <id.UHAS.9TA@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
- >In article <1992Aug08.165832.114442@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
- >> [DEC] 32-bit system 64-bit system
- >
- >> char 8 8
- >> short 16 16
- >> int 32 32
- >> long 32 64
- >> long long to be added 64
- >> pointer 32 64
- >
- >I applaud these choices. With them all normal integer sizes remain available,
- >and no valid code will be broken.
- >
-
- Hmm, perhaps I have my wires crossed here, but I thought that int was
- supposed to be processor defined, and that tiny, short and long were
- of standard size. ie.
-
- 16 bit 32 bit 64 bit
- tiny 8 8 8
- short 16 16 16
- long 32 32 32
- long long (64) (64) 64
-
- int 16 32 64
-
- with pointers implementation dependent.
-
- no?
-
- - Iain -
- --
- Iain McVey (mcvey@mpr.ca) | Kodachrome, gives us those nice, bright colours,
- Software Designer | Gives the greens of summers,
- MPR Teltech Ltd. | Makes you think all the world's a sunny day.
- 8999 Nelson Way, Burnaby, BC | - Paul Simon
-