home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / arch / 12166 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  2.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!roundup.crhc.uiuc.edu!gershwin.crhc.uiuc.edu!not-for-mail
  2. From: alewine@crhc.uiuc.edu (Neal Alewine)
  3. Newsgroups: comp.arch
  4. Subject: Precise Interrupts
  5. Date: 8 Jan 1993 13:09:41 -0600
  6. Organization: Center for Reliable and High-Performance Computing, University of Illinois at Urbana-Champaign
  7. Lines: 46
  8. Message-ID: <1ikjhlINNagf@gershwin.crhc.uiuc.edu>
  9. NNTP-Posting-Host: gershwin.crhc.uiuc.edu
  10.  
  11.  
  12. I have been trying to fully understand the implications of precise 
  13. versus restartable states relative to their affect on program 
  14. correctness in the presence of interrupts. I have read 
  15. [Smith&Pleszkun,1985], Hennessy&Patterson's Architecture book, 
  16. Mike Johnson's Super-scalar book, and many others but have not 
  17. found an actual example that clarifies the problem. 
  18.  
  19. What I am looking for is a good example (i.e., a specific scenario) 
  20. which causes program incorrectness if a restartable state is used 
  21. in lieu of a precise state. I will setup the problem the way it 
  22. appears to me. If my setup is flawed, please let me know also.
  23.  
  24. Assume there is a program sequence; a, b, c, d, e ... and it has 
  25. been reordered. Assume c excepts and an exception handler is invoked 
  26. (if c was speculated it is assumed that the exception handling has 
  27. been delayed until the branch commits and also that the hardware has 
  28. rolled back to instruction c, undoing all changes subsequent to c). 
  29. The system is now in a state which is imprecise (since it is not 
  30. guaranteed to be identical to the system state at c if the original 
  31. program sequence had executed up to c). However the state is 
  32. restartable, because without the exception (or with the exception 
  33. assuming the exception handler runs correctly and does not change 
  34. the current state), we could begin execution with the imprecise 
  35. state, at c, producing the correct program output. 
  36.  
  37. It appears that there are two potential problems with handling an 
  38. exception on an imprecise (but restartable) boundary. First, the 
  39. exception handler may need the precise state to do it's job right 
  40. or second, the exception handler fails to restore the restartable 
  41. system state upon completion. The exception to the latter case is 
  42. any changes to the system state caused by the exception handler 
  43. which could have been caused by the excepting instruction itself 
  44. are OK, since the dependencies for such changes overlap. I have 
  45. not been able to invent a specific scenario (other than debugging) 
  46. for either case without being able to apply a similar case to an 
  47. in-order sequence which also fails; indicating that a good 
  48. compiler would restrict such a case. 
  49.  
  50. Any help would be greatly appreciated.
  51.  
  52. Regards,
  53.  
  54. Neal Alewine
  55.  
  56. Keywords: scheduling, precise interrupts, speculative execution
  57.