Path: utzoo!mnetor!uunet!husc6!hao!ames!lll-tis!elxsi!beatnix!rw
From: rw@beatnix.UUCP (Russell Williams)
Newsgroups: comp.arch
Subject: Re: More than 32 bits needed where?
Message-ID: <690@elxsi.UUCP>
Date: 5 Feb 88 16:33:25 GMT
References: <235@unicom.UUCP> <28200089@ccvaxa> <3104@watcgl.waterloo.edu> <4340@ames.arpa>
Sender: nobody@elxsi.UUCP
Reply-To: rw@beatnix.UUCP (Russell Williams)
Organization: ELXSI Super Computers, San Jose
Lines: 21
Keywords: integer range, 32 bits, 64 bits

In article <4340@ames.arpa> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes:
>I also note that large multi-CPU mainframes (e.g. IBM, NAS, Amdahl,...) as
>well as supercomputers are approaching the 32 bit addressing limit for
>PHYSICAL memory.  So, I predict a healthy future for 64 bit machines in
>the "data processing" world, as well as in the scientific computing world.
>It might even be coming sooner than some people think in the micro-computing
>world.

   The per-process virtual (user instruction set) addressing limit of a machine 
doesn't necessarily limit the physical memory.  Our machine uses 32 bit virtual
addresses and 38 bit physical addresses.  Many years ago,
Honeywell machines has a 256 Kword per-process limit but could handle more
physical memory.   Of course things get more
complicated in the memory management software if you want to handle
physical > per-process, but it's often not nearly as hard to expand the
physical addressing of an architecture as it is the per-process logical limit.
It's traditionally been easier to recode your memory manager than persuade all 
your users to recompile, but Unix & C are changing that.

Russell Williams
..uunet!elxsi!rw