Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utcs.UUCP
Path: utzoo!utcs!nishri
From: nishri@utcs.UUCP (Alex Nishri)
Newsgroups: net.arch,net.micro.16k,net.micro.68k
Subject: Re: 24 bit vs. 32 bit address space
Message-ID: <472@utcs.UUCP>
Date: Sat, 9-Mar-85 21:26:22 EST
Article-I.D.: utcs.472
Posted: Sat Mar  9 21:26:22 1985
Date-Received: Sat, 9-Mar-85 22:15:57 EST
References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP> <2393@nsc.UUCP> <295@cmu-cs-spice.ARPA> <133@v1.UUCP> <181@redwood.UUCP>
Reply-To: nishri@utcs.UUCP (Alex Nishri)
Organization: University of Toronto - General Purpose UNIX
Lines: 42
Xref: utcs net.arch:915 net.micro.16k:251 net.micro.68k:632


In article <181@redwood.UUCP> rpw3@redwood.UUCP (Rob Warnock) writes:
>So if you are designing a processor family to last at least a decade,
>add AT LEAST 5 bits to what you think is "reasonable" now (more, for
>safety). I personally think we will see people complaining about 32 bits
>(based on real needs) BEFORE the current decade is out.

I am a regular attendee at SHARE (the large IBM computer user's group with
over 1,500 member installation from six continents.)  Many of the people
there are running 370/XA machines, which provide 31-bit virtual address
spaces.  There is already a small, but growing group who have run out of
virtual address space despite the 31-bits.  One person I have met at SHARE
works at Lockheed and regularly runs algorithms which require multiplication
of matrices which do not fit in a 31-bit address space.

A recent combined SHARE and GUIDE Language Futures Task Force (SHARE SSD #339)
says in part, "The limitations in dealing with large programs and large data
collections in large memories are both intellectual and technical: people
in the data processing community are not generally accustomed to thinking
that way, and the available programming tools and techniques are not adequate.
The Task Force believes that no changes should be needed to the high level
languages in order to deal with large data collections being used as though
they are entirely contained in memory.  In fact, we believe that it may
be more a matter of removing restrictions, rather than adding extensions to
the languages.  Historically, many design limits and restrictions were imposed
by yesterday's small memories (e.g. buffer sizes, limited number of
optimizable variables, etc.)  All such hardware-dependent and device dependent
restrictions should be removed."

The report goes on to discuss the fact the distinction between arrays and files
is somewhat artificial and induced by hardware limitations.  It discusses such
concepts such as persistent arrays and their advantages in application
programmer productivity.  Having humans write programs that have to manipulate
large data objects out of files instead of memory can often take up large
amounts of time -- all because memory is too limited in size.


Alex Nishri
University of Toronto, N 43 38'33" W 79 23'14"
UUCP: ...utcs!nishri
BITNET: alex at utoronto
PHONE: 1-(416)-978-7109