Experience
We've created and used these and similar tools in developing a number of embedded systems ranging in size from 40,000 to 160,000 lines of code and comprising between five and 40 intercommunicating tasks. We used PL/M, C, Pascal, and assembler for the bulk of our implementations.

We must stress that our primary motivation in developing these tools was to hide nonessential details from the application, not to enhance transportability; of course, like maintainability, transport of code is always a background consideration. The value of hiding details, generalizing interfaces, and making code self-documenting is well proven and needs no defense from us; we can, however, discuss some additional advantages these tools have offered.

At one point, CNR was required to significantly enhance a fielded system of about 75,000 lines of PL/M code that ran on an 8086. The projected size of the application and other considerations led us to choose an 80286 processor and to use VRTX. The conversion from iRMX to VRTX was substantially complete and running within a month; very little was required beyond rewriting the membrane tasks such as Send_Mail and Get_Mail. In fact, much of that one-month effort was devoted to I/O and interrupt services that weren't handled through the operating system.

These tools would make it just as easy to move from VRTX to iRMX. In fact, the only place there might be a significant interface problem is in the segment-handling membranes, Create_ Segment and Delete_Segment, since they currently require partition numbers. But the apparent difficulty disappears under closer scrutiny, and it's only necessary to change the Get_Partition and Choose_Partition routines to return the input size instead of a calculated partition number to satisfy iRMX.

We're confident that these membrane routines would allow us to move smoothly to any of the major real-time operating systems. We would just as surely use them to define the interface to our own operating system if the company is ever required to write one of its own again.

Porting between languages
Initially, the membrane tasks were written in PL/M since it has a number of constructs designed to take advantage of iRMX features. In fact, on one system developed in Pascal for use with iRMX, we used the same PL/M-based membrane tasks. With VRTX, we've used PL/M, Pascal, and C; not, we hasten to say, all on one project. Here, we chose to implement the membrane tasks in assembler.

As we took this support system from a PL/M-based project and made it available to one using C, the only substantive change we had to make was the order in which the assembler programs took parameters from the stack. Actually, when we moved to VRTX, we adopted a two-layer membrane. The outer (closer to the application) layer is in PL/M for PL/M and Pascal applications and in C for C applications; the inner layer is in assembler.

The tools described here were simple to build. They've proven to be effective, efficient aids to design, development, and debugging. Their design was influenced by our architectural approach and by the tools, languages, and operating systems available to us. The proven principles of our trade--structured programming, information hiding, and data abstraction--argue strongly that a similar approach to insulating the operating system from the application will pay off in almost any development organization.

When this article was written in 1989, Dennis P. Geller was director of software development at CNR Inc. He has cowritten several films and books on structured programming and computer information systems and holds a doctorate in computer and communication sciences. (He now works for Aptima.)

Anita Sanders was a senior project engineer at CNR and has a master's in electrical engineering.