🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #12494

Precise Interrupts

#12494
From: Neal Alewine
Date: Fri, 08 Jan 1993 19:09
46 lines
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-mail

Show 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