From 71875bd4692ca3ac4dec4c289ca4f3106a7ae97f Mon Sep 17 00:00:00 2001 From: Jason Self Date: Sun, 23 Jul 2017 12:37:48 -0700 Subject: [PATCH] Finish Appendix B; fix footnote references. --- md/debugging.md | 113 +++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 98 insertions(+), 15 deletions(-) diff --git a/md/debugging.md b/md/debugging.md index 0da1b0d..b1ae640 100644 --- a/md/debugging.md +++ b/md/debugging.md @@ -545,8 +545,8 @@ execution/evaluation proceeds. There are essentially two ways that MEND could follow the flow of control of the application program. The most direct way, as attempted -by MUMBLE[^14] and discussed in the last chapter, would be for MEND -to execute the application program by simulating the operation of +by MUMBLE[^7] and discussed in the last chapter, would be for MEND to +execute the application program by simulating the operation of Muddle. This type of simulation has been shown to require a complex end all too often fragile structure. The debugging program would need to be constantly updated to match changes and additions to the Muddle @@ -614,7 +614,7 @@ Using the collected information described in the previous section, a representation of the stack is displayed as a number of lines, each corresponding to one level. Each line shows a level number and the displayed object printed in "&-printing", named for the printing -function &[^15] created by Greg Pfister. Although strictly speaking +function &[^14] created by Greg Pfister. Although strictly speaking the stack builds upward (towards higher memory locations), it seams more natural to display and speak of the stack as building from the top downward, in the direction that printing normally occurs. As each @@ -745,10 +745,10 @@ this sort of representation. One such feature is the existence of compiled code. Although Muddle was originally intended to be a high-level interpretive language, an -assembler was written[^16], producing machine code that executes in +assembler was written[^15], producing machine code that executes in the Muddle environment, to allow programmers to create "primitives" that perform functions not otherwise available in Muddle. Once the -assembler was written, it was natural that a compiler[^17] followed. +assembler was written, it was natural that a compiler[^16] followed. It translates normal Muddle code into Muddle assembly code which is then assembled. Typically Muddle programs are tested interpretively and, when fully debugged, complied in order to obtain a major @@ -889,9 +889,9 @@ Bruce Daniels' DEBUGR is the prototype Muddle multiprocessing debugging system. It provides a simple user interface to Muddle's single-stepping functions that makes single-stepping through a Muddle program appear similar to single-stepping through an -assembly-language program with DDT[^18][^19]. The choices of -characters for invoking many of the MEND functions were based upon -the characters used to invoke similar functions in DEBUGR. Many of +assembly-language program with DDT[^2][^3]. The choices of characters +for invoking many of the MEND functions were based upon the +characters used to invoke similar functions in DEBUGR. Many of DEBUGR's command invocation characters were in turn based upon those in DDT. The object of all of this is to build character/command associations in the user's mind that may be carried over from one @@ -940,7 +940,7 @@ It is generally believed and empirical evidence indicates, that creating a new editor is "the kiss of death" for a Muddle subsystem. A number of Muddle editors have been tried over the years and the only one that finally became generally accepted (and is now -pre-loaded in Muddle) is EDIT[^20] . Members of the Muddle community +pre-loaded in Muddle) is EDIT[^11] . Members of the Muddle community will tolerate minor changes to EDIT, but they will not accept a new editing system. The situation is analogous to one of the major obstacles blocking the acceptance of ESP. Programmers were accustomed @@ -966,7 +966,7 @@ described. EDIT-format commands are all one or two letters and may take suffix arguments. Currently the MEND table includes the following commands. (FIX here means a Muddle object of type FIX, i.e., a fixed-point number. FLOAT means a floating-point number. -PPRINT[^21] is a function that prints a Muddle object in a format +PPRINT[^14] is a function that prints a Muddle object in a format which indicates the positions of its elements and sub-elements in the tree hierarchy.) @@ -1014,7 +1014,7 @@ command level where they may be examined and modified at will. Most of what constitutes MEND is in another process safely removed and hidden from the user. Even the small amount of overhead constituting the command level function is hidden from functions such as -FRAMES[^22], which may be used to view the levels of the application +FRAMES[^13], which may be used to view the levels of the application program's current control stack. The effect is much the same as that of Muddle's listening loop which is invoked at the current bottom of the stack in case of error, to allow the programmer to run any @@ -1378,10 +1378,10 @@ The third feature would allow the user to reverse execution of the application program or to simply back up to some previous point. This was suggested in two varieties, an actual undoing of all effects of the program on a step-by-step basis or simply showing previous states -of the MSTACK. The first version would have used UNDO\[\^10\], a -package of functions to actually back up a program to some previous -state. UNDO however violates a primary design goal of MEND. It works -by redefining every Muddle function that has a side-effect, thereby +of the MSTACK. The first version would have used UNDO[^10], a package +of functions to actually back up a program to some previous state. +UNDO however violates a primary design goal of MEND. It works by +redefining every Muddle function that has a side-effect, thereby causing most of the negative effects of simulation that were previously discussed. Unfortunately the way UNDO works is really the only reasonable way such a package could work, short of modifying @@ -1480,6 +1480,89 @@ Muddle by restructuring the object being EDITed according to the specifications of the programmer. EDIT allows one to define one's own commands or to redefine those of EDIT. +ENVIRONMENT: A Muddle object which specifies a particular set of +variable bindings. An ENVIRONMENT is normally cumulatively built up +as the control stack of a program builds and ATOMs are bound. The +ENVIRONMENT actually corresponds to a particular point on the control +stack. A program may have an object evaluated in an ENVIRONMENT +specifying the current state of another running program. The effect +is as if the latter program had evaluated the object. + +ESP: A debugging system for assembly-language programs. + +EVAL: A build-in Muddle function that evaluated an object and returns +the value of that object + +FIX: A Muddle object that is an integer. + +FLOAT: A Muddle object that is a floating-point number. + +FORM: A list of Muddle objects which is evaluated by applying the +first element (some function) to the rest of the elements (its +arguments). "Execution" in Muddle generally refers to the evaluation +of a FORM. The evaluation of that FORM will often require the +evaluation of other FORMs (the arguments to the function or FORMs in +the body of the function ). + +FRAMES: A pre-loaded function that shows the programmer a printed +representation of the control stack of the current program. + +IMED: An editor for Muddle objects that works by outputting an object +to the IMLAC where the local editing functions are used. + +IMLAC: A minicomputer with a keyboard and CRT display used as an +intelligent terminal. + +ITS: A general-purpose time-sharing operating system developed by the +Artificial Intelligence Laboratory at M.I.T. + +LVAL: A built-in Muddle function that returns the local value of a +given ATOM. The local value is that which was last bound to the ATOM +In the current ENVIRONMENT. + +Muddle: An applicative programming language used to inclement MEND. + +MEND: Muddle Executor, aNalyzer, and Debugger. The subject of this +report. + +MSC: Multi-Screen Console program for an IMLAC. This gives the IMLAC +used as a terminal a capability for having several virtual screens +that may be accessed and displayed independently. + +MSTACK: A structure that MEND builds to contain a representation of +the control stack of the application program. + +MUMBLE: An early debugging aid for Muddle programs providing a +display of the application program's control stack. + +PPRINT: A pre-loaded Muddle function that "Pretty-PRINTs" an object +in a format which indicates the positions of its elements and +sub-elements in the tree hierarchy. + +PRINTTYPE: A built-in Muddle function allowing the programmer to +specify exactly how any particular type of object should be printed. +May be used to output characters that will be interpreted as special +commands on input. See READ-TABLE. + +PROG: A built-in Muddle function used for sequential execution of +Muddle objects (generally FORMs). This function provides for binding +of ATOMs to be used within the PROG's scope and then evaluates each +of the objects in its body, usually in order. It is possible, +however, to alter the flow of control by branching forward or +backward to another part of the PROG body. See REPEAT. + +READ-TABLE: A table that may be set up in Muddle to specify how any +character should be treated on input. See PRINTTYPE. + +REPEAT: Like PROG except that when the end of the body of objects is +reached, control returns to the beginning. + +SSV: The normally used IMLAC console program. See MSC. + +UNDO: A Muddle program that stores information about the execution of +an application program so that the execution may be backed up to some +previous point at any time. + [^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer Journal 1973, volume 7, number 3, pages 182-198 -- 2.31.1