Newsgroups: comp.arch
Path: utzoo!utgpu!watserv1!watdragon!watsol.waterloo.edu!tbray
From: tbray@watsol.waterloo.edu (Tim Bray)
Subject: Re: R4000 "announcement" (64-bit stuff)
Message-ID: <1991Feb12.005014.2168@watdragon.waterloo.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
References: <90@shasta.Stanford.EDU> <1991Feb8.055009.9883@ico.isc.com> <45789@mips.mips.COM>
Date: Tue, 12 Feb 1991 00:50:14 GMT
Lines: 22

mash@mips.COM (John Mashey) writes:
>a bunch of stuff about how we are running up against the 32-bit barrier.

He's right.  I'm one of those people (large text databases).  Also, I had
personal experience with the painful, segmented, lurch from 16 bits to 32.

Now a native 64-bit machine would make a lot of things we want to do a *lot*
simpler.  But nonetheless, I find myself thinking seriously that a segmented
approach might not be so bad.  Reason - each additional bit past 32 buys
you *so much*.  In fact, with just an 8-bit extension, you hit a terabyte, and
it goes up (fast!) from there.

Furthermore, I worry about burning unnecessary real memory by storing 64 bits,
of which >20 are wasted, for every pointer.

I personally think the 32->64 transition is qualitatively different from
the 16->32 transition, for just these reasons.

But I think it's extremely admirable that Mipsco has bit the bullet and
given it a serious shot.  Congrats, guys (assuming you get the chips working).

Cheers, Tim Bray, Open Text Systems