From b490e1c9f15a519455ab3cefe86be60c9302c4f8 Mon Sep 17 00:00:00 2001 From: Jason Self Date: Wed, 21 Jun 2017 13:30:16 -0700 Subject: [PATCH] Adding section 6 --- md/debugging.md | 157 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 157 insertions(+) diff --git a/md/debugging.md b/md/debugging.md index a2f3045..74b736c 100644 --- a/md/debugging.md +++ b/md/debugging.md @@ -1276,6 +1276,163 @@ should be rejected in favor of a monitor-type system. MEND has proven to be an effective debugging aid and should serve as a good example of the latter type of system. +VI Suggestions for Future Work +============================== + +VI.1 Monitoring of Access +------------------------- + +Because of the problems described in Section V.1 concerning the +monitoring of values, there was not enough time to work on a related +but more interesting feature for MEND. Frequently the main piece of +information that is available about a bug Ii a program is that at some +point a certain data area (variable value, list slot, etc.) is being +"clobbered" by function(s) unknown. + +Rather than watching the program execution in detail to find the +culprit, it would be far more useful to set a break point on access to +the location in question. This could be done by having MEND redefine +all data access functions to watch for certain locations. Not only +would that be messy, but it goes against one of the basic philosophies +of MEND. With good reason, as described earlier, MEND tries to alter +its environment as little as possible. (For example, what if the +application program redefined one of the functions also?) + +Muddle again provides the answer. The code already exists for +monitoring read or write access to any standard data location. It is +only necessary to set up the proper type of interrupt handler with a +pointer to the location to be watched. Each time the specified type of +access occur, the handier will be called with all of the particulars. + +MEND should have commands installed for creating and destroying such +handlers. For consistency and to facilitate remembering for the user, +the possible actions of this handler upon being called should be +similar to those of breakpoints and of monitoring of values. + +VI.2 Other Unimplemented Features +--------------------------------- + +Three other proposed features were not implemented due to an acquired +belief that the value of each of these features in relation to the +goals of this work was not worth the time required to properly +implement it. However each of these features has merit and may be +desirable in some future, more comprehensive debugging system. + +The first such feature involves saving all output of the application +program for the programmer to refer back to. This has the +implementation difficulty that there is no easy way to separate +application program output from much of the MEND output. All +application program output and certain MEND output goes to the lower +section of the screen utilizing the same output mechanism (i.e., +standard Muddle output to the primary terminal output channel). No +distinction is made between the two kinds of output. A distinction +could be made, by having MEND do all of its output through yet another +terminal output channel (a second channel is currently used for the +upper screen section), but another consideration made the effort seem +not worthwhile. In practice, programs that produce a lot of output +usually send it to a file and not to the terminal. Since only small +amounts of output are usually sent to the terminal, a short output +history, such as that which is present on the screen itself, is +generally sufficient. + +The second unimplemented feature would have allowed the setting of +MEND breakpoints using the editor IMED. This would have meant sending +a function out to the IMLAC where, local editing would have been used +to create, or delete such breakpoints. PRINTTYPE and READ-TABLEs would +have been used to allow for setting normal breakpoints and the special +MEND types (ON, OFF, etc.) using one or two mnemonic characters. + +The primary reason that this feature was not implemented was that EDIT +wad chosen to be the MEND editor instead of IMED. That choice was made +partly because EDIT is in many respects the more powerful of the two, +but mostly because EDIT is the editor now used almost exclusively by +Muddle programmers. In fact, EDIT is now pre-loaded in Muddle while +IMED is not. Another reason for rejection of this feature was that it +would have made MEND, or at least this part of it, terminal dependent. + +In a different environment a similar feature might be quite useful. +IMED still has the large advantage over EDIT that by constantly +displaying the entire function while the programmer moves the cursor +around in it, creating and deleting MEND "command symbols" at will, +the user is provided with a much better feel for the debugging +environment being set up than with EDIT. + +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 +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 +Muddle Itself, and even UNDO is not foolproof. + +The only practical way this feature could be implemented is in its +second variety. It would be possible to store (in a file, probably) +information specifying the state of the MSTACK (at each step and to +allow the programmer to view previous steps in some comfortable +manner. The time required to implement this feature, though, put it +outside the scope of this work. + +VI.3 Immediate Action Commands +------------------------------ + +Empirical evidence suggests that one more interrupt -level immediate +action command would be highly useful. Currently the user may skip +over the complete execution of a single object by typing ↑O just after +the object is placed on the stack for evaluation. The user may also +want to rapidly complete the evaluation of some object that is already +executing. For example, one may have watched the first few objects in +a REPEAT loop being evaluated and now wants to free-run the +application program until the looping is finished. For such a case, a +command should be available to skip over the evaluation of the current +object and all others at the same level (i.e., finish evaluation of +the object on the previous level). + +Further use of MEND may indicate a need for other interrupt-level +commands. (Perhaps certain interrupt-level commands should somehow be +able to take arguments?) + +VI.4 Terminal Handling +---------------------- + +The MSC implementation of MEND was discarded because of problems +specific to the current operating environment. In a suitable +environment, multi-screening is still seen to be a useful feature for +a similar debugging system. It has even been suggested that something +of the sort could be implemented using two separate terminals. One +terminal would look to the application program just like the terminal +it would have seen in the absence of MEND. The other terminal would be +used for communications with MEND. Not only would this eliminate +output conflicts between the application program and MEND, but with +two keyboards there would be no need to have a reserved character set +for MEND interrupt -level commands. Of course, it might be difficult +for the user of such a system to coordinate activities between the two +terminals. + +Another area where MEND might be improved is its knowledge of the +terminal being used. As has been previously discussed, it currently +assumes certain basic display functions and relies upon ITS to +understand the requirements of the terminal. Although ITS handles the +job well, it is not the only operating system that Muddle may run +under. This author, in fact, actively uses Muddle under TENEX, an +operating system that lacks the terminal code to support MEND. To +properly work under most operating systems, MEND would have to be +tailorable to individual terminal codes and requirements and would +have to do much more of the work than under ITS. + +It has been proposed that MEND could be made to work in some fashion +with the basic ASCII printing terminal, something that nearly all +terminals and operating systems can simulate. However it is the +opinion of this author that MEND would lose much of its value under +such conditions. Watching the stack grow and shrink, and seeing +objects replaced by their values, gives the user more of a feel for +what the application program is doing than a long stream of +sequentially printed lines ever could. + [^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer Journal 1973, volume 7, number 3, pages 182-198 -- 2.31.1