home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / arch / 9070 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  3.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!rbbb.Eng.Sun.COM!chased
  2. From: chased@rbbb.Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.arch
  4. Subject: Re: trapping speculative ops
  5. Date: 27 Aug 1992 18:06:56 GMT
  6. Organization: Sun Microsystems, Mt. View, Ca.
  7. Lines: 60
  8. Message-ID: <l9q6e0INN919@exodus.Eng.Sun.COM>
  9. References: <GLEW.92Aug25180333@pdx007.intel.com> <CLIFFC.92Aug26084159@medea.rice.edu> <1992Aug27.005340.6547@bcars64a.bnr.ca> <CLIFFC.92Aug27082745@medea.rice.edu>
  10. NNTP-Posting-Host: rbbb
  11.  
  12. I'm a little bit mystified by the expensive approaches described here.
  13.  
  14. First, speculative division is probably not an interesting case.
  15. There are vastly more loads and stores than divisions.
  16.  
  17. However, having a "division" operator that traps is equally
  18. ridiculous.  On some machines (those that implement WORD/WORD -> WORD)
  19. division, instead of DWORD/WORD -> WORD) the check for overflow (if
  20. you care at all) is pretty simple -- division by zero for the unsigned
  21. case, and (for signed) division by zero and division of MININT (i.e.,
  22. 0x8000000) by -1.  That's it.  There are some moderately entertaining
  23. code sequences of the superoptimizer variety for detecting these
  24. things, when you care, and you can overlap the detection with the
  25. division if they are allowed to proceed asynchronously.
  26.  
  27. As far as loads and stores go, I am similarly mystified by the
  28. insistence that each and every trap from the source program be
  29. preserved in "very-optimized" code (not code compiled for debugging,
  30. or at a "normal" level of optimization).  For instance, (as has been
  31. noted by several people before me in more severely refereed forums),
  32. if page zero is mapped readable, then you can transform
  33.  
  34.   if (px != 0) x = *px;
  35.  
  36. into
  37.  
  38.   x' = *px;
  39.   /* insert other stuff here, perhaps, to cover the latency. */
  40.   if (px != 0) x = x';
  41.  
  42. No hardware support is required, but some other traps might be lost.
  43.  
  44. If the OS could be convinced to just not report illegal loads
  45. (emulating them as returning zero or NaN, for instance) then loads
  46. could be hoisted much more frequently.  This doesn't work quite
  47. perfectly -- if you store a tag in the last two bits to distinguish
  48. integers from pointers, you can lose big, because all the loads will
  49. trap to the OS -- however, it's also feasible to profile your
  50. failures, and not speculate on those loads in the next compilation.
  51. Or, your hardware (in the style of the IBM PC/RT) can silently
  52. truncate away those bits and not trap anyway.
  53.  
  54. Note that the hardware support for what I described above is pretty
  55. damn cheap.  Note that no changes are needed to the architecture.  The
  56. only cost incurred is the slightly reduced locality of reference; all
  57. those extra loads may result in extra paging.  (Someone should study
  58. this, I think.  I'm a little worried about binary search trees.  If
  59. someone is really interested, send me mail.)
  60.  
  61. Remember, we've got tools to help us debug our code.  There's Purify,
  62. and Centerline (formerly Sabre C), and something that I saw mentioned
  63. in one of the GNU lists that I wish I had made a better note of
  64. (anyone able to send me a reference, I'd be quite grateful).  People
  65. should use these tools anyway, because there's a whole world of bugs
  66. *not* caught by the hardware and OS that slips by otherwise (no saint
  67. like a converted sinner, if you know what I mean, and I think that you
  68. do).
  69.  
  70. David Chase
  71. Sun
  72.