in memory to be modified before resuming, effectively allowing the introduction of "hand-coded" temporary assignments for test purposes. Similarly, program instructions can often be skipped to determine the effect of changes to the program logic – enabling questions about program execution to be answered in a direct way (i.e. without assumptions or guesswork). In many cases it may be the only practical method of testing obscure "event-driven" error subroutines that rarely, if ever, get executed – without the added risk of leaving temporary source changes. Manually changing the resume location within a paused program can be used to enter an otherwise rarely executed section of code (such as a specific hardware condition handler). Implementing data breakpoints in software however, can greatly reduce the performance of the application being debugged – since it is using additional resources on the same processor. However, this is normally acceptable during testing and the amount of information available from the debugger is not restricted by limitations of debug data known to the hardware. For instance, a software implementation can collect logical path data at program/subroutine/instruction level to considerably augment what might be stored by the particular hardware platform for inspection. The instruction set simulation method considerably reduces the overhead, compared to the (repeated) instruction replacement method, also reducing cache misses. Some programming language implementations expose their debugging functions for use by other programs. For example, some FORTRAN dialects have an AT statement, which was originally intended to act as an instruction breakpoint. Python implements a debugger accessible from a Python program. These facilities can be and are abused to act like the COMEFROM statement. See also COMEFROM Program animation (Stepping) SIMMON References Debugging