From 9809ef867e46b8a4c64638af2b1eba2a95fac217 Mon Sep 17 00:00:00 2001 From: Jason Self Date: Sat, 17 Jun 2017 12:06:38 -0700 Subject: [PATCH] Add section 2 --- md/debugging.md | 160 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 160 insertions(+) diff --git a/md/debugging.md b/md/debugging.md index 2d8dba3..8b4fc28 100644 --- a/md/debugging.md +++ b/md/debugging.md @@ -341,6 +341,162 @@ quit useful for the analysis and debugging of Muddle programs. It should also serve as a good example of the type of debugging system that can be built around an applicative type language. +Terminal Display +================ + +IMLAC Console Program +--------------------- + +One basic concern throughout the project was the display: how the +information made available by MEND would be presented to the user. To +a large extent the physical characteristics of Muddle, ITS[^12] +(Incompatible Timesharing System, the operating system used on the +Dynamic Modeling System computer), and the available terminals +dictated what was reasonably possible. + +The terminal most commonly used by users of the Dynamic Modeling +System is the IMLAC PDS-1. This is a minicomputer capable of having +programs loaded into it from the PDP-10 host computer. One program +written for it by Dave Lebling is MSC, a multiple-screen terminal +program. Up to four virtual screens (or pages) can be created that +will individually operate like the actual screen area of the standard +terminal program (SSV\[\^13). Output may be directed to any one of the +screens and any screen may be visible or invisible at any instant of +time, at the programmer's option. Selection of screen is controllable +either by program from the host or locally by the user. + +It was originally Intended that MEND would use MSC for its normal +display. One page would constantly show MEND's representation of the +control stack of the application program. Output initiated by the +program being debugged would go to a second page. A third page would +be used for interaction with MEND and would show user typein along +with any output from MEND that one was interested in seeing. The +latter would include, by user request, full displays of both objects +printed in an abbreviated form on the page containing the control +stack of the application program and values being monitored or traced. +The user could switch back and forth among the pages at will during +the execution of the program. The application program would have a +full standard screen to write onto, and ample room would be available +for the information to be displayed by MEND. + +After a fair amount of testing, this proposal was discarded for the +following reasons. First, MSC was supposed to look just like SSV for +individual virtual screens. Unfortunately new features added to SSV +had not also been added to MSC. A primary reason for this disparity +was that the new features encroached upon the IMLAC's character space. +An SSV with all current features can only hold about one and a half +full pages of text, where a page is the amount that can be visible at +one time. The overhead required for additional screens reduces it +still further. Therefore, with all features included, four virtual +screens could each only average about one-third full. Without many of +the current features, people were reluctant to use MSC. + +The second and perhaps most devastating problem with MSC is that it is +not properly supported by ITS as is SSV. Ordinarily the operating +system will keep track of where on the page the terminal's cursor is +and will properly handle such updating as deletions even in the face +of random access performed (if done by request to the system). When +using MSC, ITS does not realize that information is being written onto +more than one screen and will therefore often move the cursor to the +wrong position. + +MEND could completely control positioning for typeout and echoing on +typein but that would add the large overhead of having to run a +non-trivial routine for each character typed out on the display. Also, +because MSC is not the standard console program, requiring the user to +load it before using MEND might discourage the use of MEND. (It takes +between about 30 seconds and a couple of minutes, depending upon +system load, to load a new console program into the IMLAC.) + +From the outset it was intended that MEND be used routinely by +programmers as debugging problems arose. Therefore it was decided that +the proper way for such a system to operate was to use, as far as +possible, the common environment so as to keep the overhead for +invoking MEND small. This philosophy, which had been seen to affect +the success of many earlier projects, decided between the alternatives +and in this case led to the final decision to use SSV instead of MSC. + +Terminal Independence +--------------------- + +The MEND terminal handling capabilities are actually quite general and +MEND does not depend exclusively on SSV. For the purpose of dividing +the screen area into several sections, horizontal lines are sometimes +drawn (see Appendix A showing sample display). With an IMLAC and SSV +these lines could be drawn quite simply using graphics mode. However, +for purposes of generality with regard to terminals, these lines are +instead formed by using underbar characters (on a line of their own). +By using no actual graphics MEND can be used with almost any display +terminal having random access. MEND outputs display commands, such as +clearing a line, as escape codes to ITS which then translates these +into the appropriate commands for the terminal in use. ITS currently +knows about several types of display terminals in use at the +Laboratory for Computer Science, and other types of terminals located +at foreign sites on the ARPA network may be handled by interface +software that simulates a known type. Naturally MEND can handle a +large range of possible line and screen lengths. (The current version +of SSV provides four possible character sizes.) + +Control of Screen Sectioning +---------------------------- + +There still remained the question of how to handle the +multi-sectioning of the displayed information. Originally three +sections corresponding to the three virtual screens in the aborted MSC +implementation were planned. The bottom section would hold user typein +and application program output. Three possible methods of achieving +this involved having ITS, Muddle, or MEND do various amounts of the +work with increasing overhead and decreasing speed for those three, +respectively. + +The most attractive solution utilized an ITS feature allowing the +specification of an echo area at the bottom of the screen where echoed +input would always be printed (with the echoing handled by the system, +which is the normal case) . After some experimentation this method of +handling the typein and application program output was rejected +because typeout and deletion are handled by Muddle which ignores the +echo area MEND would effectively have had to control all typeout and +monitor all typein, which would have made the echo area useless. + +Experimentation with the second solution, an indirect method, involved +monitoring of special Muddle memory locations where information +concerning horizontal and vertical page positions is stored. It was +soon discovered that Muddle becomes confused quickly, contains several +bugs with respect to this position information, and generally has a +poor idea of where it is actually printing. + +The third solution appeared to be the most painful from an +implementation and efficiency point of view. MEND would need to +control the printing of every character on output and certain +characters on input, constantly checking page positions by querying +the system. Not only did this slow output, but also MEND was forced to +constantly move the cursor to a safe position in case Muddle managed +to sneak some output past it, which it occasionally does. + +Fortuitously the problem was neatly solved when a little known feature +of ITS was discovered. It Is possible to open a channel to the +terminal in a mode that would cause all output to appear in the echo +area. By creating this echo area and reopening Muddle's normal +terminal output channel in this mode, it is possible to cause Muddle +and the application program to think that the entire screen consists +of only the echo area. All output including application program +display escape commands is automatically routed by ITS to this echo +area. MEND sends its output to a second channel opened in the normal +mode, thereby allowing it to use an area of the screen unknown to and +left untouched by the application program. The physical cursor stays +where the last used logical cursor left it, thereby eliminating most +of the unnecessary cursor movement, resulting in a more pleasing +visual effect. + +As a result of this solution, the screen is divided into only two main +sections. All typein appears in the lower section, whether it is to +the application program or to MEND. Application program output also +goes to the lower section, as does unstructured output produced by +interaction with MEND. The upper section, in general, contains only +those items that occupy one line of the display each. As will be +explained later, these items include all output automatically +displayed by MEND during execution of the application program. + [^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer Journal 1973, volume 7, number 3, pages 182-198 @@ -380,3 +536,7 @@ that can be built around an applicative type language. [^11]: N. Ryan, EDIT: The Muddle Editor, SYS.11.14, Programming Technology Division Document, Laboratory for Computer Science, M.I.T., August, 1974 + +[^12]: D. Eastlake, R. Greenblatt, J. Holloway, T. Knight, and S. + Nelson, ITS 1.5 Reference Manual, Memo No. 161A, Artificial + Intelligence Laboratory, M.I.T., July 1969 -- 2.31.1