Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!iuvax!watmath!grand!rwwetmore
From: rwwetmore@grand.waterloo.edu (Ross Wetmore)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Message-ID: <34791@watmath.waterloo.edu>
Date: 3 Mar 90 18:57:36 GMT
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <753@dgis.dtic.dla.mil> <WAYNE.90Feb11165528@dsndata.uucp> <3606@uceng.UC.EDU> <1990Feb15.034403.5710@world.std.com> <36080@mips.mips.COM> <42998@ames.arc.nasa.gov>
Sender: daemon@watmath.waterloo.edu
Reply-To: rwwetmore@grand.waterloo.edu (Ross Wetmore)
Organization: U. of Waterloo, Ontario
Lines: 76

In article <42998@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>In article <36080@mips.mips.COM> mash@mips.COM (John Mashey) writes:
> >costs, speed tradeofss, etc, already discussed].  Then I ask them what
> >they want it for.  [64 bit addressing. -H.L.] 
> > Usually, the answer is independent of physical memory size,
> >i.e., they want several things:
> >	a) Map big files ,and bunches of files.
> This is the primary reason as I see it.  Even in the past, I have seen
> requirements to map anywhere from 16-4000 files or separate memory
> areas [sections, segements [[not "Intel" segments]] or whatever].
> >	b) Use object management techniques that speed performance by
> >	assuming they've got monster address spaces available, evn if they
> >	aren't using very much of it at once
> This is what I see as a good reason for pushing from 48 bits to 64 bits.
> The possibility of assigning every object a memory section and therefore
> making it sharable.  

  The above seems to be a slightly incorrect partitionning of the answer.
The use of large address spaces might better be characterized by splitting
the problems into ...

a)  Large indivisible objects (eg big files)
    This is the case that did in the 80286, since 16 bits was insufficient
to handle such items even at the time the chip came out. There is no real
workaround for such cases by definition.

b)  Mapping small objects into a large address space 
    This is usually done to provide uniform addressing for shared global 
access. Or context switching efficiencies in providing data to processes 
with only a single linear address space. 

  Unfortunately, true class a) problems are a very small subset of highly 
specialized applications, though many more are cast in this mode by choice
of algorithm rather than necessity. Class b) problems are the typical case
and I would hypothesize particularly bad cases for justifying an extension
of the linear address size.

  It seems to me particularly wasteful to carry around a large number of
extra address bits on every memory reference and storage location when all 
that is often needed is a small offset value into any particular object.
The problem is inherently two-tiered, find an object and access a location
within that object, and a two dimensional addressing technique is a far
better match to these kind of operations.

  In addition, when the particular mapping of an object is changed (eg.
one removes a node from a multiprocessor and replaces it with one at a
'different' address), this means a re-link of any program(s) that have
imbedded static notions of any such addressing. Programs will be
compelled to adopt the dynamic approach of retrieving a base pointer at
run-time and writing the code as offsets from this pointer. That is
emulating the two tiered algorithm, but in an ad hoc and non-hardware
supported way. 

  One also gets into all sorts of regulatory problems in how the global 
address space (now a restricted resource) gets allocated. Alternatively, 
a 2-dimensional address space with a natural hardware supportable split
permits one to *reference* the segment internally as a logical or virtual
entity, and have the hardware automatically handle the addressing *dynamics*
including such things as protection, security and whatnot on an efficient
object by object basis. Such things can be carried out on a local level
without the need for global considerations about how someone 3000 miles
away might be allocating their global memory.

  Unfortunately, most programmers think of a process address space as a
vector, rather than an array or vector of vectors. Inate conservatism
coupled with an emotional reaction to alternative hardware or software
models tends to slow any mass movement to such new ways of thinking and
practices. Also, commercial practices do not readily lend themselves to
radical changes in direction. But perhaps it is time to rethink some of
these things and consider whether blind extension of the linear dimension
of addresses is really the appropriate choice for all current needs?

Ross W. Wetmore                 | rwwetmore@waterloo.BITNET
University of Waterloo          | rwwetmore@math.Uwaterloo.ca
Waterloo, Ontario N2L 3G1       | {uunet, ubc-vision, utcsri}
(519) 885-1211 ext 4719         |   !watmath!rwwetmore