home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / arch / 9077 < prev    next >
Encoding:
Text File  |  1992-08-27  |  1.4 KB  |  36 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!destroyer!ubc-cs!uw-beaver!tera.com!news
  3. From: bob@tera.com (Bob Alverson)
  4. Subject: Re: trapping speculative ops
  5. Message-ID: <1992Aug27.015842.17157@tera.com>
  6. Sender: news@tera.com (News Administrator)
  7. Reply-To: bob@tera.com
  8. Organization: Tera Computer Company, Seattle, WA
  9. References: <CLIFFC.92Aug26084159@medea.rice.edu>
  10. Date: Thu, 27 Aug 1992 01:58:42 GMT
  11. Lines: 23
  12.  
  13. In article 92Aug26084159@medea.rice.edu, cliffc@rice.edu (Cliff Click) writes:
  14. > Let every register have some extra "trap" bits.
  15. > A read of the register with it's trap bits set, causes the exception.
  16. > A write to the register sets the trap bits according to the success of
  17. > the operation.
  18. > 
  19. Let's see.  You'll also probably want special loads and stores that preserve
  20. those trap bits.  That way the register allocator and context switch code can
  21. safely save and restore potentially poisoned registers.  You might also want
  22. a register to register move that propagates poison, so the register allocator
  23. can shuffle values around with wild abandon.
  24.  
  25. Speaking of context switch, make sure you can restore the poison on *all* the
  26. registers or have some that you know aren't poisoned (like the one holding the
  27. stack pointer).
  28.  
  29. Oh, and those folks with conditional moves or conditional operations may want to
  30. have the poison only conditional "tasted," to keep jackpot cases from obfuscating
  31. compiler transformation decisions.
  32.  
  33. Bob
  34.  
  35.  
  36.