home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8340 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  1.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!smurf.sub.org!nadia!delos!ananke!ak
  2. From: ak@ananke.stgt.sub.org (Andreas Kaiser)
  3. Newsgroups: comp.arch
  4. Subject: 64-bit CPU vs 2 x 32-bit CPUs 
  5. Distribution: world
  6. Message-ID: <712194543snx@ananke.stgt.sub.org>
  7. References: <l7133mINN75s@spim.mips.com>
  8. Date: Sun, 26 Jul 92 23:49:03 GMT
  9. Organization: ananke
  10. Lines: 25
  11.  
  12.  
  13. In article <l7133mINN75s@spim.mips.com> mash@mips.com writes:
  14.  
  15.   > 3) The main reason is to get more address sapce (conveniently).
  16.   > There are not a *huge* number of these things; however, the ones that
  17.   > are there are *extremely* important to the people who use them, as they
  18.   > are things like:
  19.  
  20. Large applications are one reason, shared libraries (DLLs) and shared
  21. memory mappings are another. Implementing shared libraries or shared
  22. memory can enforce a global allocation mechanism, with all DLLs and all
  23. shared memory areas in the system having system-wide unique virtual
  24. addresses. Otherwise at least shared libraries could not be shared
  25. (relocation) with all processes. And this limitation can be exceeded
  26. quite soon (within some years) in a pure 32-bit virtual address range.
  27.  
  28. And there are memory mapped files as filesystem implementation
  29. technique. You clearly need more than 32-bit addressed virtual memory
  30. to implement memory mapped files. IBM added some kind of segmentation
  31. to the RS/6000, but 64-bit addressed virtual memory is easier to
  32. handle.
  33.  
  34. :::::::::::::::::::: subnet:  ak@ananke.stgt.sub.org
  35. :: Andreas Kaiser :: fidonet: 2:241/7220.9
  36. ::::::::::::::::::::
  37.