home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8407 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.0 KB
  1. Path: sparky!uunet!usc!sol.ctr.columbia.edu!ira.uka.de!news.belwue.de!news.uni-stuttgart.de!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: <712296941snx@ananke.stgt.sub.org>
  7. References: <13754@auspex-gw.auspex.com>
  8. Date: Tue, 28 Jul 92 04:15:41 GMT
  9. Organization: ananke
  10. Lines: 38
  11.  
  12.  
  13. In article <13754@auspex-gw.auspex.com> guy@Auspex.COM writes:
  14.  
  15.   > Unless, for example, your shared libraries are built in
  16.   > position-independent form; SunOS 4.x/SVR4 shared libraries don't require
  17.   > system-wide unique virtual addresses, for example.
  18.  
  19. How does SunOS handle references between different shared libraries?
  20. Vector tables in memory local to the process?
  21.   
  22.   > Shared memories don't necessarily require them, either.
  23.  
  24. Of course systems can be designed to go without having the same virtual
  25. memory address for shared memory (maybe Unixes are designed that way),
  26. but it makes handling much more difficult, since you cannot put any
  27. pointer in it. You have to use a position independant method to access
  28. that memory, whereas usual C programming highly depends on pointers.
  29.  
  30. In OS/2, shared memory it is somewhat less magic than in Unix - whether
  31. a DLL data area uses the same instance for all invocations of the DLL
  32. or there is separate data for each, is no more than a bit in the
  33. definition. Such a transparent method changes ones view of shared
  34. memory. But it is hard to implement without globally assigned virtual
  35. addresses for shared memory. Unless however, you define your own
  36. programming language for the system.
  37.   
  38.   > Umm, the machine running on my desk has a 32-bit virtual address space,
  39.   > and the OS on that machine supports memory-mapped files.
  40.  
  41.   > I would not be surprised if a movable mapping window like that weren't a
  42.   > pain, though.
  43.  
  44. Easier as moving to 64-bit addresses (well, 43 ot 55 bits or whatever
  45. is implemented in the first chips)?
  46.   
  47. :::::::::::::::::::: subnet:  ak@ananke.stgt.sub.org
  48. :: Andreas Kaiser :: fidonet: 2:241/7220.9
  49. ::::::::::::::::::::
  50.