Programmer's ROM - The Computer Language Library

home *** CD-ROM | disk | FTP | other *** search

/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / educ / port1.doc < prev next >

Wrap

Text File | 1988-05-03 | 33.2 KB | 856 lines

Subject: Major Ada porting technical report Date: Fri, 15 May 87 08:25:36 EDT From: Lt Col Francis L Falgiano III <falgiano@mitre.ARPA> The following is a paper presented at the WWMCCS application and systems software committe meeting. The authors want to share some of their experiences with other Ada users. TRANSPORTING A MAJOR ADA APPLICATION Prepared by: Joe Tenney Don Whiteley Honeywell Federal Systems Inc. Honeywell Federal Systems Inc. Project Team J. Tenney D. Whiteley Honeywell ADA Development Group E. Kearns D. Ward W. Munsil (Subcontractor APSE, Inc.) SAC Airborne Developers Providing Project Support Cpt. G. Butcher Lt. T. Brooke Lt. E. Schulz Ssgt. C. Rasmussen I. MIMS REHOSTING PROJECT I.1. Rationale DOD Directive 5000.31 ..."The Ada programming language shall become the single, common computer programming language for defense mission-critical applications. Effective 1 January l984 for program entering advanced development and 1 July l984 for programs entering full scale engineering development, Ada shall be the programming language."..... Undersecretary of Defense Delauer 10 June l983 The Delauer pronouncement considers Ada to be more than just another high level language. Ada is considered to be a full fledged software engineering environment that translates into simplified large-scale software development signaling an end to machine dependence. The Ada compiler system is to be reliable, easily maintainable, and portable. Although reliability and maintainability would be a function of abstraction and design, the portability criteria is of prime import in providing a universal computer language. Ada development at Honeywell dates back to the original design procurement process of the Department of Defense. The language finally accepted as a result was the version proposed by Honeywell. I.2. Introduction On 25 November l986, Honeywell Federal Systems Division and the Headquarters Strategic Air Command Airborne Division (Offutt AFB, NE), agreed to attempt porting the Mobile Information Management System (MIMS) to a Honeywell DPS90 platform. Previous attempts by Vendors other than Honeywell to rehost MIMS were unsuccessful due to the maturity level of their compilers. The release of the MIMS software package to Honeywell was projected to accrue benefit to the government by gaining experience in porting Ada code, demonstrating the protability of mission-critical command and control software, and the usability of Honeywell's Ada environment. Honeywell was presented with an opportunity to test their new GCOS8 Ada compiler using the complex programming constructs contained within MIMS. I. 3. MIMS MIMS is a full featured relational information management system written entirely in the Ada programming language and containing 66,000 plus lines of code (25,000+ lines of Ada source statements). It is being developed to provide a productive environment for the development of battle management application programms to support SAC's Post Attack Command and Control System (PACCS). It provides the capability to describe and manipulate data as relations, without user concern for physical links and pointers. It also provides the capability to write applications programs using either Ada or a fourth-generation data management language patterned after ANSI standard SQL. This language, called Extended-SQL, contains all the commands necessary to: 1) Describe, manage, and manipulate relations. 2) Perform selective queries against single or multiple relations. 3) Develop applications programs. 4) Describe side-effects for any attribute. A side- effect is a procedure that executes automatically any time its associated attribute is changed. A side-effect procedure can contain any statements allowed in an application program. MIMS has two major components: a data management and a language processor. The data management component provides the single point of access to the data base, insuring integrity, security and access protection of the data. The language processor interprets sequences of Extended-SQL commands into requests to the data management component. I.4. Host System The host/development system is a ROLM MSE-800 Ada Work Center with 8mb of memory and 277mb of disk storage. The ROLM MSE-800 is a ruggedized version of the Data General MV80000 system. It runs Data General's AOS/VS operating system revision 4.01 and the ADE 2.3 version of the ROLM/Data General Ada compiler. The terminals used on this system were normally Dasher 200's and Dasher 460's. I.5. Target System The target system is a Honeywell DPS90 with 96mb of memory and 5000+ mb of disk storage. The DPS90 is an NEC1000 sold under the Honeywell label in the United States. It runs the pre-release version of Honeywell's GCOS8-SR3000 operating system and the pre-validated version of Honeywell's virtual Ada compiler. Honeywell's Ada compiler is a version of the Dansk compiler re-hosted on a Honeywell DPS8, 88, and 90 level system. The target terminal was Honeywell's VIP7801 in asynchronous/character mode. I.6. File Conversion The first task in the porject as to convert the source tapes created on the Data General to Honeywel format. To acomplish this a physical record dump of the tape was obtained to ascertain its format. Once the record format was defined, a 'C" program to do the actual conversion from tape to disk source file was written. Although some problems were encountered in source lines spanning physical records, this protion of the project was completed within 30 man-hours. I.7. Initial Functionality Testing The next step was to determine the ability of our compiler to successfully compile MIMS. For this we chose a sample timing test and the MIMS Tools package. The timing tests compiled and executed without any problem. The results of the timings showed a mixed view. We saw from these reports that file preparation (e.g. opening, closing, and creating), was significantly slower on the Honeywell system due to the overhead of a large operatinng system and a large file structure. On the other hand, I/O speeds were greatly improved on the Honeywell, due largely to the Software Disk Cache buffering facility. Compilation of the tools package proceeded with one small complication. The heap size test failed when attempting to allocate over 1mb of heap space. This problem was caused by memory limitations on programs generated by Honeywell's current validated Ada compiler. Once run on the new, then un-validated virtual compiler, the heap size could be grown for beyond the needs of MIMS. I.8. System Dependent Routines Adjudging no major problems in the test compilations, we proceeded headlong into the full port of MIMS. The first item attacked aws identifying the system dependent characteristics of MIMS. After talking with the MIMS developers and previewing the source code, we identified the following areas: 1) A Data General Package named TTY_IO had been used to perform I/O to the terminals. This allowed control functions that would have been stripped by Data General's TEXT_IO routines to be passed between terminal and program. MIMS depends heavily on the use of function keys an control characters, so some new way had to be found to tersmit this information on the Honeywell system. 2) A Data General package named SYSTEM-CALLS was used to perform file maintenance (e.g. file copying and renaming). No corresponding routines currently existed on the Honeywell system. 3) A Data General package named CURRENT_EXCEPTION was used to return the name of the last exception encountered. This would be very useful in identifying error returns from various routines and was used extensively throughout MIMS. No corresponding facility existed on the Honeywell system. 4) The MSE-800 used no front-end communications processor, which enticed the MIMS developers to take total control of all terminal I/O on a character-by-character basis as no buffering of data was done. This included parsing each character input for validity, field placement, control function execution, and echo printing. The Honeywell system used a DN8 communications processor, which, by default, buffered the I/O and sent the buffer only upon receipt of certain control information. Although the line could be configured to transfer data a character at a time, the amount of system overhead required to accomplish this form of I/O would be prohibitive in a large, multi-user environment. 5) A Data General Math package contained on their Ada system library had no equivalent on the current Honeywell Ada library. The protability aspect of MIMS was well thought out by its designers. All of the system dependent routines were called from individual packages, which renamed these routines for use by all other MIMS routines. This made the task of isolating and changing these routines far less complex than would have occurred if these calls were spread through all 149 source files. The function keys and cursor control routines were also isolated and easily identified. Our initial perception was that none of the system dependencies would be easily resolved and some I/O and system calls might present a major stumbling block. The CURRENT_EXCEPTION routine was easy to dummy out by simply returning a default string of all calls to this function. However, we found later that this made troubleshooting much more difficult. Eventually the Honeywell Ada development group in Phoenix developed a package similar to CURRENT_EXCEPTION which returned the name of the exception, and the package the exception was defined in. Due to the exception being stored in a stack in Honeywell's impementation, this routine could not be made compatible with the one from Data General, but did prove helpful in isolating several problems. To repalce the Data General math package we obtained a copy of a math package contained on the Ada repository. This package surprisingly had all the routines necessary to satisfy the calls from MIMS, and even returned values in the same format. All that was needed was to change the names of some of the called routines in the single MIMS interface package. The file maintenance interfaces proved to be a more difficult task, as no current direct link to Honeywell's file system existed from Ada yet. However, the only ones that could not be accomplished by an Ada routine were the renaming and physical copying of a file. Discussion with the MIMS developers led us to the conclusion that these features were only used on rare occasions and could easily be disabled. I.9. Terminal I/O That left us with the major problem of terminal I/O. There were several question marks in this area and a multiplicity of ways to approach the subject. Our choice was to attempt to use TEXT_IO to accomplish this, and to suggest to the Ada development group any minor modifications we may need in TEXT_IO routines to allow us to successfully complete the task. If the TEXT_IO routines could be modified to support unfiltered, full screen I/O, it would allow future users a much easier method of accomplishing this same purpose. Our first test was to write and I/O echoing routine which showed the user the ASCII codes corresponding to the input and then echoed back the input. In this fashion we could test successful transfer of control characters. We were pleasantly surprised to find out that Honeywell's TEXT_IO package could already pass control functions back and forth successfully to the VIP7801, negating any need for modification in this area. Our next step was to modify the MIMS terminal I/O packages to use TEXT_IO and the VIP7801 control sequences. We then needed an application to invoke the routines in these packages to perform the I/O. The MIMS developers, being more familiar with what they needed to see, wrote an application for us, which exercised the terminal's input and output abilities. Running this program brought some errors to light. 1) The 1280 byte TEXT_IO output buffer overflowed when using special cursor control and screen formatting characters. The Ada development group had to enlarge the size of the output buffer to correct this problem. 2) MIMS uses reverse video to outline viewports and other pertinent information on the screen. When the reverse video portion needed to be erased, they merely wrote blanks over these locations on the Dasher terminals to accomplish this. The VIP7801, however, stored the starting and stopping positions for reverse video as control information in the VIP. It required specific reset commands to these positions to turn off the reverse video. This was difficult to accomplish due to the number of places reverse video was used, and the fact that they had designed no facility to store all viewports currently displayed, making them difficult to find and erase, short of clearing the entire screen. This same problem also occurred to a lesser degree with underlininng and blinking. It took over two man-weeks to clean up this area alone. In retrospect, it would have been better to use the VIP7801 graphics features as they would have been more compatible with the MIMS code than the special screen formatting. 3) Buffer transmissions to the terminal were being terminated with a carrige return/line feed, whi caused incorrect cursor positioning when requesting following input. The Ada development group modified the TEXT_IO routines to eliminat this. Although we had anticipated serious problems in buffering the terminal I/O, after correcting problems 1) and 3) above we could not find any cases where it caused us major anomalies. We did notice system status messages that were time dependent were queued until the buffer was transmitted, but changing these messages to PUT_LINES eliminated that problem. I.10. Compilation Once the system dependent routines were either replaced or had work-arounds, we proceeded with the compilation of the 68 packages that comprise MIMS. We started by stringing all the compilations together into a single run, but soon found that we were wasting a considerable amount of time due to errors encountered in earlier compilations. It proved more efficient to step through the compilations one at a time during this phase. Several of the errors we encountered were due to compilation order, which had to be resolved before we could continue. The complexity of this problem when dealing with 149 source files increased the time spent resolving the correct order. A later examination by the MIMS developers uncovered an incorrect file order on the original source tape they had given us. The next order of business was to trouble-shoot the remaining compiler errors and aborts. We knew that these packages, short of our changes, had successfully compiled and executed on another system. Therefore the problems we were currently encountering could be lumped into three categories. 1) Errors in our modifications. 2) Errors in MIMS code not detected by the Data General compiler. 3) Errors caused by the Honeywell compiler. We, needless to say, encountered errors in our modifications which had to be resolved. We also found two instances where the Honeywell compiler detected an incorrect matching of a formal private type to an actual limited type which the Data General compiler had not detected. This is in violation of a rule specified in section 12.3.2. of MIL-STD-1815A. We found several compile time errors and aborts caused by our compiler which are enumerated in an addendum to this report. By working closely with the Ada development group we were able to either correct, or work-around, all of these problems. Once all packages compiled successfully, a timed run showed a compile time of 2 hours, 48 minutes for all 68 packages, a considerable improvement over the smaller MSE-800 system. I.11. Elaboration and Execution The first attempt at elaboration brought to light a difficult and too lightly regarded area of this project, the run-time errors. We had weighed the possibilities of the compiler generating incorrect code, but had under estimated the complexity of these problems and the time required to resolve them. The bulk of the time we spent on this project was involved in this area. By use of a master mode debugger and debug statements, we set to work on the long, tedious process of identifying these errors. A symbolic debugger would have been a great boon during this portion of the project. A lot of time was spent attempting to determine and set an elaboration order. The Data General system insured all "WITH" dependencies for a package were elaborated before attempting to elaborate the given package. In most cases this prevented the need for PRAGMA ELABORATE statements, unless the order needed to be changed. The Honeywell system elaborated by an order dependent on the unit number in the library, which changed whenever that unit was re-compiled. To avoid this problem we had to place PRAGMA ELABORATE statements into the specification and body of every package for al its dependencies. The other run-time errors we encountered during elaboration and execution are enumerated in an addendum to this report. These problems were much more severe than the same problems would have been if encountered during a development phase, as every problem had to be approached from a total system perspective and worked back to the failing code. Each step along this path required insertion of debug statements, re-compilations, re-linking, and execution; making each step a very time consuming process. At times during elaboration it left one with a feeling of attempting to chop one's way out of a forest. Each time a tree was felled, another was encountered just behind it. Persistence and perseverance did pay off though. On February 12 we were able to fully elaborate MIMS, after two months of effort. Once fully elaborated we encountered fewer run-time errors in the remaining code, due in part to corrections made on the compiler. Some minor modifications to our changes were required in the area of terminal I/O, but otherwise we were mostly ready to proceed to the next step of executing an ESQL application to demonstrate full functionality. I.12. Full Functionality Testing For this the MIMS developers working with us developed an unclassified demonstration program, which creates a relational database and performs various retrieval and update functions to exercise the majority of MIMS code. We installed and ran this application with few problems, but we were not totally pleased with its performance on the DPS88. Response times were only slightly improved over the MSE-800 and, in some cases, actually slower. Considering the power differences between the two processors, we initiated a study to determine why MIMS was running slower on the DPS88. A trace of file opens and closes soon made it very clear where our slowdown was occurring. In a 15 minute period of elaboration and execution we had over 2200 lines of file opens and closes. On the MSE-800 they are limited to a maximum of approximately 200 files open and therefore opened and closed files quite profusely. This cost them very little on their small system, but on our system we were opening files almost six times slower than they were and it was hurting the system performance sorely. Under SR3000 users are allowed to have in excess of 2000 files open. One possible way around our performance problem was to leave all the MIMS files open, closing them only upon termination and therefore avoiding the overhead. At the time, Ada would only support in the proximity of 200 files due to the buffer requirements for these files. Working with the Ada development group, we were able to devise a method to allow Ada users to allocate a number of files up to the system limitation. The performan ce improvement in MIMS caused by this change was dramatic. We saw our response time improve on the order of 3 to 8 times. Elaboration time, which was taking over 9 minutes, was now under 3. Although we saw other areas for improvement, we felt the performance was now at an acceptable level and further efforts in this area were beyond the scope of our project. Once we had proven acceptable performance on the DPS88 we transferred the executable file, libraries, and the applications files to a development DPS90 system at LCPD. Our execution on this system ran without error and showed approximately a 30% improvement in performance over the DPS88. This was the final step in the port of MIMS to a Honeywell DSP90 system. On March 16, l987 we installed the final demonstration application and on March 18 this demonstration ran to a successful competion. The entire project, including functionality testing, had spanned nearly four months and included over three months actual work. Not including support the Ada development group and the MIMS developers supplied on this project, the two project analysts spent approximately 1500 man hours to accomplish the port. This number does reflect time spent in isolating compiler errors and thus may not be a valid representation of total time required to port other Ada applications. We would estimate that 15 percent of the total man hours were actually spent converting MIMS code. I.13. SUMMARY This project represented one of, if not the first, port of a major Ada application from one hardware platform to another. As such, it represents a milestone in the proof of the portability concept of Ada programs. It is our feeling that even given the youth and problems encountered in our compiler, the time spent to port MIMS was quite reasonable for a major application. At the outset of the project we were somewhat concerned by articles and papers we had read concerning the level of difficulty of the Ada programming language. However, we found as we proceeded through the project, these concerns were simply unfounded. Although both analysts on the project had several years of data processing experience, and accessability to the Honeywell and MIMS Ada developers, both had a minimum of Ada training in preparation for this activity. We found that Ada was both flexible and versatile, allowing constucts for the beginning programmer, as well as the advanced. Ada programs can also be easily understood when well written, however, as with any language, there is well written and poorly written code. Most of MIMS was well written and well thought out, making it much easier to port. Their method of constraining all system dependent calls to a few packages made finding and replacing them a much easier task. It will be difficult to avoid using system dependent routines in any major application, but care in their use and placement will enhance portability. Some of the naming conventions were overused and made debugging somewhat more difficult as the same name was used for different purposes in several routines. The USE statement also caused difficulty during debugging and our opinion was that in most circumstances it should be restricted to system or common package names. The availability of tools currently is of a concern. The compilers appear to be too young and too little used to be equipped with all the hooks and handles that, for example, COBOL compilers have. Flux within the specifications os SQL has slowed down efforts to adopt an Ada/SQL interface to a system dependent database. Other interfaces and tools may be slow in coming until the suppliers see a more concerted direction in the Ada community. We did encounter several compiler errors. However, there is no error-free compiler of any language on the market today. This is a very important aspect to consider in any porting effort. Any project of this nature must plan on encountering a certain number of compiler errors, and allowances in time schedules made accordingly. Although we were able to find methods of coding around most errors, there may be problems that arise which cannot be avoided and require a correction to the compiler. These errors should become less common as the Ada validation suite becomes more stringent, but in all likelihood will still remain a nemesis to other porting projects. Problems of this nature may be minimized for applications requiring a base on multiple hardware platforms by keeping program constructs simple, and by avoiding use of "fringe" areas in the language. Ada development appears to be at a critical stage. Now that some of the larger companies have fielded an Ada compiler there appears to be some reluctance in upper management to invest resources in this area until a more defined path is set. The attitude in the commercial world is of mild interest, but nobody appears to be ready to make a mad dash toward writing new applications in Ada. They appear to be watching the federal sector to see how committed they really are. Currently their view is of strongly worded directives for new development in Ada, immediately followed by exemptions to develop in other languages. There appears to be a lot of in-fighting in the federal community on their commitment to Ada, and until these are resolved and a firm direction set, one may not see much movement in the commercial sector towards Ada, and thus only limited support for an Ada environment supplied by the major manufacturers. The federal sector, and especially the military, have to spearhead any push towards Ada. Without this impetus, Ada will likely die on the vine in the same manner as JOVIAL. Not to allow Ada to flower into a major language environment would be to deny all the reasons it was originally developed and would mortally wound any chance to language standardization for the future. In our opinion, Ada has the necessary fundations to become a base for most future development efforts and deserves to be carefully examined and nurtured to bring about its successful fruition. II. Problems Encountered with the Honeywell Virtual Ada Compiler During the MIMS Project 1. If a deferred type is declared in a package specification, and another package which references that type is compiled before the full type declaration in the body, the compile may abort in Pass 6 with an "Error 27 - Unexpected Data Structure". Avoidance: Put the full type declaration in the Package Specification. Correction: None 2. Using "RENAMES" to define an internal element of a generic record type in another package may cause the compilation to abort with a numeric eror abort. Avoidance: Delete the "renames" clause and use the full field name, or if it's an "in" only parameter being "renamed", simply make the new name a local object. Correction: None 3. Compilations occasionally abort with a storage error abort. Avoidance: Re-submit the compile. Correction: Correction to the operating system dynamic memory manager. 4. Instantiating a dynamic array in a generic package may cause a numeric error in the package currently elaborating. Problem seems to only occur in large or complex compilations. Avoidance: Create multiple generic packages, each containing a static array. Correction: None 5. Constraints on generic arrays may not be passed when using "Renames" causing a constraint error when attempting to access an element in the array. Avoidance: Delete the "RENAMES" clause and use the full field name. Correction: Problem resolved by the Ada development group. 6. Discriminant record types in complex packages may cause numeric or constraint errors when attempting to use. Avoidance: Remove the Discriminant parts of the record. Correction: None 7. The <type>'value attribute when used with any type causes a storage error. Avoidance: None Correction: Problem resolved by the Ada development group. 8. The <type>'value attribute makes a distinction between upper and lower case and may cause a NAME error if the value and the element do not have the same letters capitalized. Avoidance: Insure the use of capitals in the spelling of the element name. Correction: Problem resolved by the Ada development group. 9. Aggregate assignments may cause various problems when used to reference complex structures. Avoidance: Remove the aggregate parts of the assignment. Correction: Problem corrected by Ada Development. 10. A function return inside a block within the function can cause a storage error. Avoidance: Do the function return external to the block. Correction: None 11. When certain structures containing an array of arrays are defined, the compiler may incorrectly try to optimize the code in PASS8, causing invalid data to be stored in the arrays. Avoidance: None Correction: Problem corrected by Ada Development. 12. The enerated Ada libraries could not grow over 16384 links. Avoidance: Use multiple libraries with parenting. Correction: Problem resolved by the Ada development group. 12. Ada libraries tend to de-generate after repeated modification, destroying current occupants of the library. Avoidance: None Correction Problem resolved by the Ada development group. III. Enhancements to Honeywell's Ada System Made During the MIMS Project The following enhancements were made to facilitate the handling of various constructs in MIMS. However, future development efforts in Ada on a Honeywell system will also be enhanced by having these features available. 1. Problem MIMS used a Data General routine called TTY_IO to send data to the terminal without stripping out control characters. Data transmission was unbuffered character-by-character. The Honeywell system buffers all TEXT_IO to the terminal until receipt of a new_line, put_line, or GTE in the program. This caused a problem with the data buffers overflowing when transmitting a full screen of data. Solution It would be ideal to have TEXT_IO handle all forms of I/O to the terminal, thus avoiding the need for any separate, system-dependent packages. As Honeywell"s TEXT_IO package already passed VIP7801 control characters, all that was added were larger buffers for TEXT_IO to accommodate a full screen of data. Although the time of delivery of some messages (those sent to the terminal a character at a time) was delayed, the buffer transmission conditions caused us far fewer problems than we had anticipated. 2. Problem All buffer transmissions to the terminal were terminated with a NEW_LINE which caused the cursor to be incorrectly positioned when doing full screen data transmissions. Solution The NEW_LINE was removed from the transmission leaving the cursor positioned correctly. 3. Problem The increased time required to open a file on a large scale system as opposed to the ROLM/DG became prohibitive during the execution of MIMS. A trace to file opens, over elaboration and ten minutes of execution, showed over 1100 opens of the 240 attached files. Solution A change was made to allow the system maximum 2000 files to be open. This allowed us to change MIMS to delete file closings, and thus the subsequent file opens. By so doing, we were able to obtain execution times in the order of 3 to 8 times faster. 4. Problem The ROLM/DGG system had a very useful routine which returned the name of the last exception, thereby avoiding the need for multiple exception conditions to trap the error encountered. Solution A routine was added to the Ada library on the Honeywell to return not only the name of the exception, but the library unit number of the package or procedure it was defined in. This routine is not compatible with the ROLM/DG routine of the same name.