home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / bsd / 10249 < prev    next >
Encoding:
Text File  |  1992-12-15  |  2.6 KB  |  54 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!bogus.sura.net!pandora.pix.com!stripes
  3. From: stripes@pix.com (Josh Osborne)
  4. Subject: Re: Shared lib benchmarks, and experiences
  5. Message-ID: <BzBB3G.EyK@pix.com>
  6. Sender: news@pix.com (The News Subsystem)
  7. Nntp-Posting-Host: pandora.pix.com
  8. Organization: Pix Technologies -- The company with no adult supervision
  9. References: <1giendINNgku@life.ai.mit.edu> <1992Dec14.231025.12627@rwwa.COM> <BzAEnE.GKq@ra.nrl.navy.mil>
  10. Distribution: usa
  11. Date: Tue, 15 Dec 1992 17:54:50 GMT
  12. Lines: 40
  13.  
  14. In article <BzAEnE.GKq@ra.nrl.navy.mil> eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:
  15. [...]
  16. >    Offhand, I do not see why the number of entry points represents a
  17. >problem.  The general structure of a sharable library under linux is that we
  18. >start with the jump table itself.  This is usually padded to some large size to
  19. >accomodate future expansion.  [...]
  20. > [...]   There is no
  21. >reason a priori that we even need to use up the jump vector slots in any
  22. >particular order.  We could use them randomly if we wanted to, although it
  23. >would serve no useful purpose to do so.
  24.  
  25. Ahhh, the jump table order is user definable.  Good trick, that solves alot of
  26. problems.
  27.  
  28. [... PIC disscusion...]
  29.  
  30. >    There was another objection that has been raised in the past by various
  31. >people, and that is that in the 3/486 architecture there are relatively few
  32. >machine registers compared to something like a VAX.  The PI code that I have
  33. >seen GCC generate always seems to use up one register as a reference pointer of
  34. >some kind or another, and when you reserve this register (usually ebx) for this
  35. >purpose, it is not available to the compiler for other uses, and this could
  36. >lead to poorer performance.  I have not seen any numbers to back this up,
  37. >but the objection has been raised.
  38.  
  39. Well, you do have some segment registers free.  You wouls have to add a kernal 
  40. call that allowed to you add entries in the segment descriptor table (and
  41. verifys that they are valid segments), but once that's done you could use
  42. "far calls" (or even change CS).  I'll admit it's ugly, but it would be almost
  43. as fast as non-PIC code (segment loading takes a few cycles, and far calls/
  44. segment overide takes a extra cycle or 2, all the k-calls would be done at
  45. lib load time, and not be much of a problem).
  46.  
  47. [...]
  48. -- 
  49.            stripes@pix.com              "Security for Unix is like
  50.       Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
  51.       "The dyslexic porgramer"                  - Kevin Lockwood
  52. We all agree on the necessity of compromise.  We just can't agree on
  53. when it's necessary to compromise.       - Larry Wall
  54.