home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!auspex-gw!guy
- From: guy@Auspex.COM (Guy Harris)
- Newsgroups: comp.arch
- Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
- Message-ID: <13754@auspex-gw.auspex.com>
- Date: 27 Jul 92 01:36:28 GMT
- References: <l7133mINN75s@spim.mips.com> <712194543snx@ananke.stgt.sub.org>
- Sender: news@auspex-gw.auspex.com
- Organization: Auspex Systems, Santa Clara
- Lines: 28
- Nntp-Posting-Host: auspex.auspex.com
-
- >Implementing shared libraries or shared
- >memory can enforce a global allocation mechanism, with all DLLs and all
- >shared memory areas in the system having system-wide unique virtual
- >addresses. Otherwise at least shared libraries could not be shared
- >(relocation) with all processes.
-
- Unless, for example, your shared libraries are built in
- position-independent form; SunOS 4.x/SVR4 shared libraries don't require
- system-wide unique virtual addresses, for example.
-
- Shared memories don't necessarily require them, either.
-
- >And there are memory mapped files as filesystem implementation
- >technique. You clearly need more than 32-bit addressed virtual memory
- >to implement memory mapped files.
-
- Umm, the machine running on my desk has a 32-bit virtual address space,
- and the OS on that machine supports memory-mapped files.
-
- The OS doesn't support memory-mapped files larger than 2GB, but then it
- doesn't support files larger than 2GB, period. A future version of the
- OS may support files larger than 2GB, although it may not let you
- memory-map chunks larger than 2GB or 4GB or so if you don't have an
- address space larger than 4GB; you may have to map part of the file, and
- move the mapping window around.
-
- I would not be surprised if a movable mapping window like that weren't a
- pain, though.
-