D.R. Hanson. Event association in SNOBOL4 for program debugging. Software - Practice and Experience, 8(2):115--129, 1978.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... execution [13, 19, 20] the underlying interpreter can indeed be extended with special support for debugging and performance monitoring, and events like variable referencing, statement execution, program interruption, function call and return, execution run time errors can be easily detected [12]. However, even using interpreted execution, common limitations of previous environments seem to be lack of portability, generality, and availability. Furthermore, interpretation slows down the running time. However, this may not be highly critical in applications like debuggers and software ....

D.R. Hanson. Event association in SNOBOL4 for program debugging. Software - Practice and Experience, 8(2):115--129, 1978.

....reaches this position. Position independent breakpoints are conditions on the current state of program execution which do not depend on a particular location. Although the advantages of such breakpoints were already identified in [Bal69] few debugging systems actually incorporate these features [Han78, OCH91] The watchpoints of gdb [SP91] are another example of position independent breakpoints: execution is suspended when the value of a given expression changes. Below, we will outline how both types of breakpoints can be obtained. Our starting point will be the conventional breakpoint on ....

D.R. Hanson. Event associations in SNOBOL4 for program debugging. Software - Practice and Experience, 8:115--129, 1978.

....language, there is a wide range of choices for the granularity of steps. An execution step can be a construct from a high level language at one extreme or a machine instruction at the other extreme. Each step is described by an event. The use of events in monitoring process behavior is common [2, 6, 7, 13, 15, 16, 19, 23]. Usually events provide only that subset of process behavior which is important for a particular application. For example, Hanson [6] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have ....

....a machine instruction at the other extreme. Each step is described by an event. The use of events in monitoring process behavior is common [2, 6, 7, 13, 15, 16, 19, 23] Usually events provide only that subset of process behavior which is important for a particular application. For example, Hanson [6] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have been implemented in interpretive environments [6, 16] or by augmenting source code to emit events [3, 23] Although the content of ....

[Article contains additional citation context not shown here]

D. R. Hanson. Event association in SNOBOL4 for program debugging. Software--Practice and Experience, 8(2):115--129, March/April 1978.

....made them attractive, but a satisfactory way to incorporate garbage collection and a sophisticated run time environment in introspective systems was not found. Therefore, the decision was made to use C. Each step is described by an event. The use of events in monitoring process behavior is common [15, 64, 66, 111, 120, 121, 150, 168]. Usually events provide only that subset of process behavior which is important for a particular application. For example, Hanson [64] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have ....

....the decision was made to use C. Each step is described by an event. The use of events in monitoring process behavior is common [15, 64, 66, 111, 120, 121, 150, 168] Usually events provide only that subset of process behavior which is important for a particular application. For example, Hanson [64] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have been implemented in interpretive environments [64, 121] or by augmenting source code to emit events [24, 168] Although the content of ....

[Article contains additional citation context not shown here]

D. R. Hanson. Event association in SNOBOL4 for program debugging. Software-- Practice and Experience, 8(2):115--129, March/April 1978.

....in real time, but usually they are not a standard part of computer equipment and are not integrated into programming environments. Therefore, general programming tools cannot rely on the availability of hardware monitors. Software approaches to monitoring include event generation and processing [1, 3, 6, 8, 12, 13, 14, 17, 18]. An executor, written in a high level language, produces events that are related to concepts in that high level language. Examples of such events include function calls or changes in variable values. Events are processed by event handlers included in the program itself [10] by a postprocessing ....

D. R. Hanson. Event association in SNOBOL4 for program debugging. Software--Practice and Experience, 8(2):115--129, March/April 1978.

No context found.

D.R. Hanson. Event association in SNOBOL4 for program debugging. Software - Practice and Experience, 8(2):115--129, 1978.

No context found.

Hanson, D. R. Event Associations in SNOBOL4 for Program Debugging. Software --- Practice and Experience, 8:115--129, 1978.

No context found.

Hanson, D. R. Event Associations in SNOBOL4 for Program Debugging. Software --- Practice and Experience, 8:115--129, 1978.

No context found.

D.R. Hanson. Event association in SNOBOL4 for program debugging. Software - Practice and Experience, 8(2):115--129, 1978.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC