Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!ico!ism780c!news
From: news@ism780c.isc.com (News system)
Newsgroups: comp.arch
Subject: Re: 64 bits
Message-ID: <46173@ism780c.isc.com>
Date: 9 Aug 90 18:57:30 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <13667@cbmvax.commodore.com> <40644@mips.mips.COM> <1990Aug8.042631.7093@nlm.nih.gov> <1990Aug8.215735.4197@zoo.toronto.edu>
Reply-To: marv@ism780.UUCP (Marvin Rubenstein)
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 20

In article <1990Aug8.215735.4197@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
<In article <1990Aug8.042631.7093@nlm.nih.gov> states@tech.NLM.NIH.GOV (David States) writes:
<<<     ... 64-bit integers & pointers, not just 64-bit
<<<     datapaths, which micros have had for years in FP).
<<
<<Maybe, but aside from address generation and floating point, what are
<<people going to do with all those bits?  Setting aside address arithmatic,
<<most of the time you don't need 32 bit integers and lots of work involves
<<bytes or smaller (character strings etc.).
<
<You've just answered your own question.  They'll use 64 bits for the same
<thing they use 32 bits for:  address arithmetic.  Making integers and
<pointers the same size will be primarily a concession to badly-written
<programs (which *know* the two are the same size) and marketing (which
<wants to be able to say "64 bits!" without qualifications).

But because the difference between two pointers is a number we still need a
numeric type with the same number of bits as a pointer.

     Marv Rubinstein