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