home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8409 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.5 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.arch
  4. Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
  5. Message-ID: <13795@auspex-gw.auspex.com>
  6. Date: 29 Jul 92 05:59:05 GMT
  7. References: <13754@auspex-gw.auspex.com> <712296941snx@ananke.stgt.sub.org>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 45
  11. Nntp-Posting-Host: bootme.auspex.com
  12.  
  13. >  > Unless, for example, your shared libraries are built in
  14. >  > position-independent form; SunOS 4.x/SVR4 shared libraries don't require
  15. >  > system-wide unique virtual addresses, for example.
  16. >
  17. >How does SunOS handle references between different shared libraries?
  18. >Vector tables in memory local to the process?
  19.  
  20. Yup.  Calls made by a shareable object to other routines (even to
  21. routines that are static to a module, at least with the SunOS bundled
  22. compiler; hopefully, other compilers are smarter about that) go through
  23. the Procedure Linkage Table, which is a process-local jump table.
  24.  
  25. >  > Shared memories don't necessarily require them, either.
  26. >
  27. >Of course systems can be designed to go without having the same virtual
  28. >memory address for shared memory (maybe Unixes are designed that way),
  29.  
  30. The UNIX systems I know of *allow* you to ask that shared memory
  31. (whether it's SV shared memory or "mmap"ped shared memory) be put at a
  32. specific virtual address, assuming you know what address to give it
  33. (said address, of course, must be unused by the process running your
  34. program).  They also allow you to ask the system to choose an address.
  35.  
  36. >  > Umm, the machine running on my desk has a 32-bit virtual address space,
  37. >  > and the OS on that machine supports memory-mapped files.
  38. >
  39. >  > I would not be surprised if a movable mapping window like that weren't a
  40. >  > pain, though.
  41.  
  42. My phrasing was a bit more ornate than it should have been, and I ended
  43. up saying the opposite of what I wanted to say, namely that I wouldn't
  44. be surprised if having to use a movable mapping window *WAS* a pain -
  45. i.e., I suspect it *is* a pain.
  46.  
  47. In any case:
  48.  
  49. >Easier as moving to 64-bit addresses (well, 43 ot 55 bits or whatever
  50. >is implemented in the first chips)?
  51.  
  52. I suspect "easier as" may be a transliterated German usage, with which
  53. I'm unfortunately unfamiliar; do you mean that the using such a window
  54. is easier than (to use a English - or, at least, US English - phrasing)
  55. moving to 64-bit addresses, or that moving to 64-bit chips is easier
  56. than using a movable mapping window, or that mapping large files will
  57. get easier as we move to 64-bit addresses?
  58.