MAKING THE MOVE TO MODULA-2

J.V. Auping and J.C. Johnston

Three years ago, we had occasion to upgrade a group of small scientific computers used for laboratory data acquisition. We chose to standardize all of our new software efforts and use Modula-2. In this article, we'll talk about why we chose Modula-2 and about the benefits and drawbacks of the language.

As support programmers for a materials research laboratory, we are involved in writing application programs that perform control functions and acquire data from special-purpose experimental furnaces. There are about a dozen such furnaces for controlled heating and cooling of metals and alloys and for crystal growth activities. Each furnace had been initially equipped with a data acquisition and control system made up of a small desktop computer that was programmable in Basic and an IEEE-488-based data acquisition unit. As our researchers came up with more complex experiments, we were limited by the speed and memory capacity (32K words of user space) of the desktop computers.

In addition, as the researchers became familiar with the capabilities of the PC systems appearing in their offices, they grew dissatisfied with the small display and slow tape drives of the data acquisition computers. The decision was made to replace the old computers with faster, larger, PC-type systems. We had been quite satisfied with the capabilities of the data acquisition units, and also had invested significant amounts of time in the wiring of thermocouples and other transducers. We were determined to keep them with whatever new systems we developed. This put some constraints on our choice of hardware.

After a survey of the available computers, we settled on an 80286-based AT-compatible system with a 40-Mbyte hard disk and EGA display. We also chose an IEEE-488 interface card that promised code to support most of the popular programming languages. Since we had been dissatisfied with the cryptic nature of even our own most carefully written Basic code, we were pleased to have the chance to move to a more satisfactory programming language. This was an important decision for us, because we wanted to standardize on one language throughout the lab. As the different furnaces have many functions in common, we wanted to be able to share code.

The first language we considered was Pascal, as one of us had had considerable experience with it prior to this project. After trying to apply Pascal to our experiments, we decided we liked the strong typing and structured design of the language, but were concerned that it would be unable to support a joint programming effort. We had been intrigued by literature{1,2 that described Modula-2 as a language designed for team programming. Its similarity to Pascal was convenient, and it seemed well-suited to joint projects that required low-level access to the computer hardware. So, we decided to test a Modula-2 development system.

We were particularly interested in and wanted to evaluate a number of features described in the articles on Modula-2:

• The modular structure, which would allow two or more programmers to work in a controlled manner and permit code interaction without unforeseen side effects.
• Transparent access to the low-level facilities of the machine without disturbing the rest of the program.
• Increase in program reliability because of built-in type checking.
• The idea of creating independent modules that can be used in other programs.

• The issue of case sensitivity. All of Modula-2's identifiers are case sensitive, and reserved words are required to be uppercase.
• Modula-2's inability to do I/O on complex types (records and arrays, for instance) directly, without byte counting.
• The relative scarcity of commercial software libraries available for Modula-2.

The first step in developing our library was to determine exactly what capabilities it would provide. We were pleased with the plotting functions available in the Basic ROMs in our small computers, and we decided to include many of these functions but improve on the calling syntax. This gave us a base set of "high-level" procedures that would have to be implemented. These would be the only procedures invoked directly by an applications programmer using the library. We defined a number of other functions that would be needed either as additions to the base set or as lower-level functions required to implement the base calls.

  Low-level Hardware Manipulation Functions

  Determine what graphics devices are available
  Move the active position to the specified device coordinates
  Draw from the active position to the specified device coordinates
  Draw a label string
  Clear the video screen and set to text, graphics, or menu (no
  cursor) mode

  High-level Plotting Functions

  Initialize the graphics functions
  Choose a plotting device for subsequent output
  Set plotting boundaries
  Set boundaries for a scaled area
  Set the scale for the scaled area
  Set the type of plotting units
  Set the size of characters for subsequent labels
  Set the angle for subsequent labels
  Set the line type for subsequent draw commands
  Set the pen color
  Set the background color
  Set the label orientation relative to the active position
  Set the number of digits to the right of the decimal point
  Return the ratio of the physical dimensions of the plotting area
  of the current device
  Set the character font to be used in subsequent labels
  Draw a line from the active position to the specified coordinates
  Move to the specified coordinates
  Do an incremental draw from the active position
  Do an incremental move from the active position
  Draw an X-axis with tic marks
  Draw a Y-axis with tic marks
  Draw a set of X-Y axes with tic marks
  Draw an X-Y grid
  Draw a label at the active position according to the current
  character size, label orientation, and label angle settings
  Draw a set of X-Y axes with tic marks, labelled according to the
  current character size and fixed decimal settings
  Draw an X-Y grid, labelled according to the current character
  size and fixed decimal settings
  Draw a box around the current plotting area
  Draw a symbol of specified size and type at the active position
  Return the coordinates of the active position
  Clear the screen and set the mode

Of course, the big question is, how did the use of Modula-2 affect the process of writing a team-programming project? Our feeling is that the modular nature of the language streamlined the process of writing and testing each function. Granted, this could be done with any "good" structured language, but the formal, definition module/implementation module structure made it particularly easy to isolate and group similar procedures.

Comparison with our past experience shows that the strict typing of Pascal or Modula-2 eliminates the source of a lot of errors that creep into Basic or Fortran programs. In comparing Pascal to Modula-2, it is more difficult to see a great difference. The tendency (in well-written programs, at least) for Modula-2 programs to be broken into many small parts makes the isolation and elimination of errors easier than in Pascal and makes Modula-2 code more reliable from the outset than Pascal or C code. We have, of course, found occasional bugs in our library during the past year and a half. Almost all of these, however, have been due either to errors in logic or to timing problems caused by moving to machines with different clock speeds.

The reusability of modules is an important part of the rationale behind Modula-2. Once you write and debug a module you can put it in your library and use it whenever you need that function again. A problem arises in modules that import information from other modules. GDriver imports a module called HdwDefs. That means that GDriver can't be used in another program unless HdwDefs is available too. We have found that the most easily reusable modules are often the lowest-level ones that perform one simple, clearly focused function. Reusability of more complicated modules must be planned for in the original design of the code because you need to minimize the number of dependencies.

On the other hand, GDriver is a general-purpose drawing and labeling module available for any program needing it. This approach is preferable to writing the same functions again the next time they are needed. In a broader sense, this was the purpose of the entire plotting package. It provides a simple interface for a programmer who needs to add some simple graphing functions to a program. As a byproduct of its creation we now have a number of modules that we can use anytime.

The issue of transparent access to low-level facilities was also important to us. Some of the functions that we require in our experiments involve the use of boards that plug into the AT bus. Many of these require special software to access their registers and onboard memory. Modula-2 has enabled us to do that quite successfully. Some of these devices use interface code that is wholly or partially written in assembly language but is called from a Modula program as if it were any other module. Modula-2 can access individual memory locations and I/O ports, allowing the programmer to do much of this manipulation without resorting to assembler. It is, however, a good idea to isolate any such extremely machine-dependent code in its own module.

Error handling has been and continues to be more of a problem. If an external error occurs deep in a nested set of procedures, there is no easy way of invoking some error-handling procedure unless an error flag is tested each step of the way back. For example, if the plotter goes offline during a plot (someone inadvertently turns it off or the paper-load lever is moved), the transmission code deep in the low-level routines will eventually time out, generating a serial error. The error is posted in a variable in DataDefs along with a string explaining the problem. There is no way to guarantee that the calling program will notice this condition unless the error flag is checked after every call to GDriver. This means that every call to DrawAbs, MoveAbs, or DrawString in GDriver has to be checked, and the rest of the calling routine short-circuited, returning an error indication to the external calling program. This issue has not been resolved to our satisfaction. Our working solution has been to have the low-level code that discovers the error post a message to a reserved area on the display screen explaining the problem and giving the user a chance to fix it.

One unanticipated benefit of Modula-2 has been that it allows us to maintain our own coding styles and habits and a sense of ownership of our own code without impeding the collaboration necessary to make a project like this work. (As you may have gathered, we have not progressed to the point of "egoless" programming. We are, at best, pursuing "ego-reduced" programming.) For example, one of us likes the indented structure:

  IF SomeCondition THEN
       DoThis;
       ThenThat;
   ELSE
       DoSomethingElse;
   END (*if*);

while the other prefers:

  IF SomeCondition
       THEN
           DoThis;
           ThenThat;
       ELSE DoSomethingElse;
   END (*if*);

The fact that we can each write and maintain our own code in separate modules means that neither has to put up with the other's unspeakably ugly IF-THEN style.

We expected that the language's case sensitivity would turn out to be an annoyance. Instead, we have found that once you are used to the rules it isn't a burden at all, especially if you use a syntax-assisted editor. In fact, we have both grown to like the fact that reserved words are all in caps. Using normal capitalization for variable and procedure names allows you to quickly pick them out from the reserved words in the code. Case sensitivity forces you to clean up the variable names so they all match exactly. In Pascal, case insensitivity allows you to put off cleaning up the code to make it prettier. Modula-2's case sensitivity does have a drawback in that it makes some new errors possible. It is legal to declare a local variable with the same name as a global variable. No changes can be made to the global variable inside the procedure where the local variable is declared, protecting the global from unforeseen side effects. However, if you miscapitalize the declaration of the local you can inadvertently change the global. This situation actually occurred in some code a student wrote for us, and it took quite a while for us to help him locate the problem.

A real annoyance with Modula-2 is that it has no equivalent for Pascal's get and put statements, which allow a program to automatically handle I/O on complex data structures such as records. In order to write a record variable in Modula-2, a program has to calculate the size of the record and then write that number of bytes. Presumably, this is in keeping with the philosophy that all I/O in Modula-2 would be through a procedure specific to the data type involved. It would be nice if there were a more automatic way to do this. The random access I/O of data to/from disk files has the same kind of limitation, also probably for the same reason. It seems that the compiler could do this for you.

Another drawback of using Modula-2 becomes evident if you are writing a short program from which you want quick results. There is some significant overhead in typing in the numerous FROM SomeLibrary IMPORT SomeProcedure; statements necessary to do any useful task. For a while, we both returned to Turbo Pascal when we had to do something quickly. Eventually, as we became more involved with Modula-2, we evolved template main program modules that contain the imports (such as WriteLn, WriteString, Assign, Concat, and so forth) that we typically use in our work. However, there are still the frustrating times when you discover at compile time that you've forgotten to import one or more of the procedures you need.

The scarcity of commercially available software libraries for Modula-2 was not an insurmountable problem for us. We invested about six months in writing our own utility routines, including both a program to produce straightforward scientific plots and a useful set of generic field editing routines. We have also successfully used packages designed to be called from other languages, with more or less trouble depending on what memory model the library uses. One image-processing library written to be called from Microsoft Pascal required an assembly language interface module to rearrange the stack so that the arguments were passed correctly.{3

After extensive use, we have both become rather fanatical about Modula-2 and have standardized on it for all new development in the lab. We have hired undergraduate and graduate students for summer jobs who were able to learn the language quickly and produce modules for us in reasonably short periods of time. We have certainly met resistance from programmers unfamiliar with Modula-2, but we have adhered to our decision to maintain a single language.

In short, we feel that Modula-2 has delivered on its promise to be very suitable for multiprogrammer projects. Its modular structure has allowed us to write efficient, reusable code that can be used in a variety of applications. At this point, we're looking forward to more support, both commercial and user group.

1. "Modula II, An Overview -- Excerpts From A Talk By Niklaus Wirth," Micro Cornucopia (Aug/Sept 1985), 25.

2. N. Wirth, "History and Goals of Modula-2," BYTE (August 1984), 145.

3. C. Johnston, "Modula-2 in the Mainstream," Computer Language (June, 1989), p.71.

NASA does not endorse commercial products. Details about any products named in this article were included for completeness and accuracy. No endorsement or criticism of these products by NASA should be assumed. The source code for the entire package is available from the authors upon request.

_MAKING THE MOVE TO MODULA-2_ by J.V. Auping and Chis Johnston