Article View: comp.arch
Article #12494Precise Interrupts
From: Neal Alewine
Date: Fri, 08 Jan 1993 19:09
Date: Fri, 08 Jan 1993 19:09
46 lines
2839 bytes
2839 bytes
I have been trying to fully understand the implications of precise versus restartable states relative to their affect on program correctness in the presence of interrupts. I have read [Smith&Pleszkun,1985], Hennessy&Patterson's Architecture book, Mike Johnson's Super-scalar book, and many others but have not found an actual example that clarifies the problem. What I am looking for is a good example (i.e., a specific scenario) which causes program incorrectness if a restartable state is used in lieu of a precise state. I will setup the problem the way it appears to me. If my setup is flawed, please let me know also. Assume there is a program sequence; a, b, c, d, e ... and it has been reordered. Assume c excepts and an exception handler is invoked (if c was speculated it is assumed that the exception handling has been delayed until the branch commits and also that the hardware has rolled back to instruction c, undoing all changes subsequent to c). The system is now in a state which is imprecise (since it is not guaranteed to be identical to the system state at c if the original program sequence had executed up to c). However the state is restartable, because without the exception (or with the exception assuming the exception handler runs correctly and does not change the current state), we could begin execution with the imprecise state, at c, producing the correct program output. It appears that there are two potential problems with handling an exception on an imprecise (but restartable) boundary. First, the exception handler may need the precise state to do it's job right or second, the exception handler fails to restore the restartable system state upon completion. The exception to the latter case is any changes to the system state caused by the exception handler which could have been caused by the excepting instruction itself are OK, since the dependencies for such changes overlap. I have not been able to invent a specific scenario (other than debugging) for either case without being able to apply a similar case to an in-order sequence which also fails; indicating that a good compiler would restrict such a case. Any help would be greatly appreciated. Regards, Neal Alewine Keywords: scheduling, precise interrupts, speculative execution
Technical Details
Message-ID:
<1ikjhlINNagf@gershwin.crhc.uiuc.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!roundup.crhc.uiuc.edu!gershwin.crhc.uiuc.edu!not-for-mailShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!roundup.crhc.uiuc.edu!gershwin.crhc.uiuc.edu!not-for-mail From: alewine@crhc.uiuc.edu (Neal Alewine) Newsgroups: comp.arch Subject: Precise Interrupts Date: 8 Jan 1993 13:09:41 -0600 Organization: Center for Reliable and High-Performance Computing, University of Illinois at Urbana-Champaign Lines: 46 Message-ID: <1ikjhlINNagf@gershwin.crhc.uiuc.edu> NNTP-Posting-Host: gershwin.crhc.uiuc.edu