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
[^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
projects / mudman.git / commitdiff