Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!udel!haven!uvaarpa!murdoch!madras!clc5q
From: clc5q@madras.cs.Virginia.EDU (Clark L. Coleman)
Newsgroups: comp.arch
Subject: Re: Be Prepared...
Keywords: Lots Of Memory
Message-ID: <1991Feb28.183404.19076@murdoch.acc.Virginia.EDU>
Date: 28 Feb 91 18:34:04 GMT
References: <4517@alliant.Alliant.COM> <62994@bbn.BBN.COM>
Sender: usenet@murdoch.acc.Virginia.EDU
Organization: University of Virginia Computer Science Department
Lines: 31


The referenced articles discuss multiprocessor systems with 4GB of real
memory, or the potential to be built with 4GB of real memory.

The point seemed to be that 32-bit addressing was not sufficient, as we
are going to hit the 4GB barrier soon.

My question: Do these machines put all 4GB or 2GB in one linear address
space? I tend to doubt that each of the 128 Intel i860 processors in
the referenced post can address each others' memory in this fashion.
More likely that they each need to address much less than 4GB, in which
case we seem to have lost the original point of the discussion.

I am sure that we will need more than 4GB at some point (especially for
some rare but demanding applications), and that we can chew up 4GB of
address space with memory mapping of the I/O, but the question remains
whether 4GB of REAL memory (not disk drives mapped into memory), 
addressable by any single processor (including a processor within a
multiprocessor system) is "just around the corner".

By the way, the Hewlett Packard Precision Architecture can use two
32-bit address registers to perform 64-bit addressing, and has done so
for several years now. Yet press announcements from various companies
seem to claim that they are now the first with this capability. 64-bit
ALU registers are a different story.


-----------------------------------------------------------------------------
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offence." E.W.Dijkstra, 18th June 1975.
|||  clc5q@virginia.edu (Clark L. Coleman)