home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / arch / 9393 < prev    next >
Encoding:
Text File  |  1992-09-13  |  3.0 KB  |  62 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!psinntp!psinntp!equator!jod
  3. From: jod@equator.com (John Setel O'Donnell)
  4. Subject: Re: trapping speculative ops
  5. Message-ID: <1992Sep12.170954.3708@equator.com>
  6. Organization: Equator Technologies, Inc., Seattle, WA
  7. References: <CLIFFC.92Aug28085924@antigone.rice.edu> <1992Aug31.224611.5196@odin.diku.dk> <Btvou1.6F9@news.orst.edu>
  8. Date: Sat, 12 Sep 1992 17:09:54 GMT
  9. Lines: 51
  10.  
  11. In article <Btvou1.6F9@news.orst.edu> pmontgom@math.orst.edu (Peter Montgomery) writes:
  12. >In article <1992Aug31.224611.5196@odin.diku.dk> thorinn@diku.dk 
  13. >(Lars Henrik Mathiesen) writes:
  14. >>To summarize: trap bits are proposed to enable a compiler to move a
  15. >>potentially trapping operation outside of a condition. As a special
  16. >>case, this would allow many, if not all, of the same optimizations
  17. >>that can be done if a load through a NULL pointer yields zeroes.
  18. >
  19. >    On the early models in the CDC Cyber series, such
  20. >as the CDC 6400 and 6600, floating point errors
  21. >(e.g., overflow, division by zero) generated special
  22. >results (e.g., indefinite quantity).  They did not generate
  23. >a trap until those NaN-like results were used as operands
  24. >to other floating point instructions.
  25.  
  26. In the Multiflow TRACE family of machines, there were several architecture
  27. features to support moving operations above IFs.
  28.  
  29. - There was a floating-point mode called "deferred exception" that acted
  30. similarly to what's described above.  Register-to-register floating
  31. point operations didn't signal exceptions; overflows wrote Inf, other
  32. failures wrote NaN.  Chains of operations could move above an If.  We
  33. checked for Nan/Inf when doing the following operations:
  34.     - store to user memory (2 variants of store opcodes, one for 
  35.                 spill/restore, one for user stores which
  36.                 performed the check on the data)
  37.     - convert to int    (don't want to lose exception status)
  38.     - floating compare    (likewise)
  39. This mechanism lost underflows; most users didn't care.  There were
  40. compile-time options to specify whether to use precise exceptions or
  41. this mode.
  42.  
  43. - There were 2 types of LD opcodes, one called "dismissable."  If no
  44. valid address translation existed for a DLD, the target register 
  45. was loaded with -1 (a NaN, and an unaligned pointer to boot) and 
  46. the computation continued.  The compiler rewrote LD->DLD when making
  47. a scheduling decision to move a LD above a branch.
  48.  
  49. I'm aware of experimental implementations on other systems of the latter
  50. feature without hardware modifications, by changing the TLB-miss/page fault
  51. code to check a bitmap in the process address space which specifies which
  52. PC's have DLD's.
  53.  
  54. This is written up in ASPLOS-II (10/87) and IEEE Trans. Computers, 8/88.
  55. Comments on the second (improved) implementation of these features are
  56. in a paper in Supercomputing '90.
  57. -- 
  58. - - -
  59. John Setel O'Donnell                      jod@equator.com
  60. Equator Technologies, Inc.                206-328-6544 voice/fax
  61. Seattle, WA                               Read everything by Alice Miller.
  62.