Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!mcsun!hp4nl!svin02!rcpieter
From: rcpieter@svin02.info.win.tue.nl (Tiggr)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <1381@svin02.info.win.tue.nl>
Date: 3 Sep 90 14:22:29 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>
Organization: Eindhoven University of Technology, The Netherlands
Lines: 38

paulh@cimage.com (Paul Haas/1000000) writes:

>In article <3656@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>>
>>Not at all.  Nobody was proposing a new kind of pointer.  The suggestion
>>was to have *one* kind of address *only*, namely a bit address.  Only the
>>size of addressible units was to change.

>Bit address pointers seem like a new kind of pointer to me (-:.
>In C-speak the new type of pointer would be "pointer to bitfield",
>"pointer to bit", or "pointer to short short char" (look ma, no new
>keywords).

Richard was right.  There will not be any new type of pointer, since
all pointers will point to a bit.  It is a mere coincidence that a
pointer to an int will not only affect the bit it actually points
to, but also the following 31 (or 63) bits.  But this is already the
case on current machines (substitute byte for bit, 3 for 31 and 7 for
63 in the previous sentence).

Talking of C, no new key(buzz)words will be needed.  Imagine declaring
a 3bit variable i you will access as an integer subrange, and the
corresponding pointer to this bitfield:

int i:3, (*p):3;

>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...

Tiggr