Ada 95 Transition Support

SECTION 3
MODULAR MISSION COMPUTER
(JOINT STRIKE FIGHTER - LOCKHEED MARTIN)

3.1 Executive Summary

The Joint Strike Fighter Modular Mission Computer (JSF-MMC) Ada 95 conversion project began in July 1996 and will continue until January 1997. The project is sponsored by the JSF Project Office and is being conducted by engineers at Lockheed Martin and Texas Instruments located in Fort Worth and Plano, Texas, respectively. The project involves converting the existing Operational Flight Program (OFP) written in Ada 83 to Ada 95. The project is using the distributed system annex to implement distributed execution of the OFP over four to six workstations.

While the project is still in its early stages, several technical lessons have been learned:

3.2 Project Introduction and Overview

The JSF-MMC Ada 95 project is using the existing F-16 Modular Mission Computer (MMC) Operational Flight Program (OFP) and F-22 Mission Software, both written in Ada 83, to investigate Ada 95 tool sets and several aspects of the Ada 95 language. The project is being conducted by Lockheed-Martin Tactical Aircraft Systems (LMTAS) with Texas Instruments (TI) as a subcontractor.

Questions to be answered, as part of the JSF-MMC effort, are:

The MMC OFP implements the mission control function of the Block 50 F-16, including navigation, electronic instrument presentation, and weapon delivery. The OFP consists of four (4) programs of approximately 800,000 lines of Ada 83 code. The OFP executes on four MIPS 4400 processors connected by a PI-bus backplane, in real-time, using 50 Hertz deadlines.

The Avionics Simulation Environment (ASE) is a test environment that provides simulated F-16 subsystems, external environment, and targets for the MMC OFP. The ASE executes on one or more SPARC-based Sun workstations and communicates with the OFP through shared memory and UNIX signals. To operate with the ASE, the OFP under test is recompiled to target Sun's SPARC processor, using a modified operating system-layer Ada Virtual Machine Interface (AVMI), which executes on Sun's Solaris rather than on the actual target hardware. The four OFP programs execute as separate UNIX processes. One of the goals of this project is to replace some of the interprocess communications with the facilities of the Distributed Systems Annex.

3.3 Ada Technology

Discussion

This project is in a relatively early stage of development. The main technical issue addressed so far is the effort to convert the existing OFP and AVMI to Ada 95. The primary lesson learned is that the differences and non-compatibilities between Ada compilers from different vendors meets or exceeds the upward incompatibilities involved in converting to Ada 95.

The following lists the changes required to compile the OFP under GNAT 3.05 and execute the program with the minimal ASE. Full execution with the fully functioning ASE has not yet been achieved (as of Summer 1996) due to the lack of full support for priorities in GNAT 3.05 and errors encountered during elaboration.

Ada.Exceptions - The routines in AR_Error relied on a VADS-specific package to get exception information. In order to make this work in Ada 95, another parameter had to be added to the error routine called to report an exception. The Ada 95 approach uses Ada.Exceptions to supply the correct routines.

Added 'size attributes - There were Unchecked_Conversions between objects of different sizes. Some of these warning messages were removed by adding 'size attributes to some types.

Address Clause needs constant - GNAT (Ada 95?)* requires that the address used in an address clause of the type "for X use at Y" be a constant. These can be fixed by declaring a constant just before the object and giving the constant the value used in the address clause that follows.

Address Math - Several routines did address math using operators out of System. In Ada 95, these operations are in System.Storage_Elements.

Adjust Priorities - System.Priority in VADS is from 0..99 and in GNAT it is 0..31. So, a mapping of priorities had to be performed.

Ambiguous character literal - This is a known Ada 95 upward incompatability.

Bug fix in aggregate assignment - A bug was found in an aggregate assignment; a workaround was installed.

Bug in packing - A bug was found in packing a particular record; a workaround was installed.

Bug in priorities - A delay was added in one place to get around a situation where a lower priority task was running while a higher priority task should have been running.

Call-Back - The Ada 83 code contains packages that supply "call-backs" by allowing client packages to instantiate a generic subprogram with a subprogram to be called. The body of these supplier packages was modified to use Ada 95 features instead of the VADS CIFO pragma Invoke_By_Address.

Commented out pragma External_Name - Some packages contained pragma External_Name in order to make objects visible in the linked output. This was not necessary for our work, so the pragmas were commented out.

Elaborate_Body - Packages that Ada 95 does not allow to have bodies existed with bodies supplied. Adding a pragma Elaborate_Body to the package specification requires the body to be supplied.

External ==> Export - Pragma External was used to export external names. These were converted to the Ada 95 pragma Export.

Illegal case element from subtype - There was a case statement that cased off of a subtype but included an element from the parent type in the case.

Initial_Priority ==> Priority - The VADS CIFO defines a pragma Initial_Priority to be used instead of pragma Priority so that dynamic priorities can be used.

Interface ==> Import - The Ada83 pragma Interface is replaced in Ada 95 with pragma Import.

Interrupt task - There was a task that had an interrupt associated with one of its entries. For Ada 95, this task was converted to a protected type.

May_Make_Access_Value - The CIFO defines a pragma May_Make_Access_Value that warns the compiler that a type may be used to access static objects. Ada 95 defines a standard mechanism to do this.

No_Addr - VADS has a constant System.No_Addr that is System.Null_Address in Ada 95.

Pragma Initialize - VADS supplies a pragma Initialize that indicates that the data in a package should be re-initialized when the program is restarted. For now, these have all been commented out.

Pragma pack so for size works - Some types that had representation specifications associated with them needed Pragma pack to also be applied to them.

Removed interface to MOVC3 - An assembly language routine MOVC3 was interfaced to in order to move data. This interface was changed to use Memory.Copy.

Removed interface to memcpy - An assembly language routine MOVC3 was interfaced to in order to move data. This interface was changed to use Memory.Copy.

Removed rep spec from discriminant rec - There was one discriminated record that contained a representation specification which GNAT (Ada 95?) did not allow.

SigUsr1 ==> SigUsr2 - The interrupt associated with the PI_Bus emulation task was associated with SigUsr1. GNAT reserves SigUsr1, so SigUsr2 was used instead.

Storage_Elements - When memory.copy was recoded, the type of the size parameter was changed from an integer type to System.Storage_Elements.Storage_Offset. This affected all the packages that called Memory.Copy.

Suspiciously modified rep specs - There were a couple of representation specifications that had to be modified to remove some dummy fields. This may be a GNAT problem.

Type conversions - There were some type conversions where intermediate results would raise constraint_error, but the result would not. GNAT complained about it even though VADS did not.

Universal_Identifier ==> Task_IDs - In AVMI there were some packages that used Universal_Identifiers (a MACS-specific package) instead of Task_IDs (a CIFO package). These could all be changed to use Task_IDs.

Unsigned_Types - This VADS package is replaced in Ada 95 by modular types.

Unused declarations - There were some instantiations of unchecked_conversion that weren't actually used. This is related to the Unused With problem.

Unused variable - There were declarations of variables that were never used. The GNAT compiler gives warnings when compiling these.

Unused with - There were some With's of packages that don't exist in the application and weren't actually used. These were usually in packages that had been modified for AVMI.

Use type required? - A package in FR required a Use Type in an odd place.

Use type - WHY? - When compiling a package that has a generic subprogram that relied on an Operator Renames for the package body, no error message was generated. However, when the subprogram was instantiated, an error message was given that no operator was visible. Adding a use type or moving the Renames into the subprogram body fixed the problem. This may be a GNAT bug.

V_I_Bits - This was a Verdix package used to manipulate unsigned_integers. It supplied operations like "or" and "and". In Ada 95, modular types supply the needed functions.

V_I_Except - This is a Verdix package that can be replaced (mostly) with Ada.Exceptions.

With for elaborate - Some packages With another package from the specification and then have a pragma Elaborate in the package body without repeating the With from the package specification. GNAT (Ada 95?) requires the package also be withed from the package body.

Following is a count of the number of files which needed to be changed to implement the changes described above:

1 Ambiguous character literal
1 Bug fix in aggregate assignment
1 Bug in packing
1 Bug in priorities
1 Illegal case element from subtype
1 May_Make_Access_Value
1 Removed rep spec from discriminant rec
1 Sigusr1 ==> Sigusr2
1 Suspiciously modified rep specs
1 Unused declarations
1 Unused variable
1 Use type required
1 V_I_Bits
1 V_I_Except
2 Interrupt task
2 Removed interface to MOVC3
2 Removed interface to memcpy
2 Use type - WHY?
3 Initial_Priority ==> Priority
3 Pragma pack so for size works
4 Adjust Priorities
4 Interface ==> Import
4 Unsigned_Types
5 Commented out pragma External_Name
6 Added 'size attributes
6 With for elaborate
8 Unused with
10 Address math
10 Universal_Identifier ==> Task_IDs
13 Ada.Exceptions
18 Address Clause needs constant
24 Storage_Elements
26 External ==> Export
54 Call-Back
64 Type conversions
65 No_Addr
135 Elaborate_Body
179 Pragma Initialize

3.4 Staffing

Discussion

The project staff consists of a Project Manager/Lead Engineer, a Lead Engineer, and two Senior Software Engineers. All the staff has extensive experience developing real-time avionics software using Ada 83. Three staff members were new to Ada 95 while the fourth member was involved in the Ada 9X language review process.

3.5 Mentoring

Discussion

Since the development staff is quite experienced in Ada 83 software development and is deeply familiar with the software being converted, little on-site mentoring has been required. Mentoring support has been concentrated in the following areas:

  1. Identifying and acquiring appropriate tools, assisting in tool installation, and facilitating tool bug reports and new feature requests;

  2. Assisting in the design of the distributed implementation and the use of the distributed systems annex; and

  3. Suggesting areas of interest and means for approaching the overall software analysis (e.g., Ada 95 features to examine and evaluate).

3.6 Training

Discussion

Ada 95 training was provided during July 1996 at the Lockheed Martin facility in Fort Worth, Texas. The training was provided by Mr. Patrick Rogers of Software Arts and Sciences. The training lasted two weeks. Both the instructor and students were pleased with the training experience and the resulting competence gained.

Lesson Learned

3.7 The Development Environment

Discussion

The hardware environment for both the development and demonstration system is a group (4 to 8) of Sun SPARC 20 workstations. GNAT is the compiler being used. The version of GNAT in use is updated as new releases become available. Interprocessor communication is achieved through a standard TCP/IP network.

Lessons Learned

3.8 Conclusions

The difficulty of converting a real-time Ada 83 application to Ada 95 appears no greater than converting from one Ada 83 compiler to another. Most required changes related to the use of non-portable, compiler-specific features in the legacy code. Future porting of the Ada 95 code will be simplified since most of these compiler-specific features can be replaced by standard, portable features in Ada 95. As of Summer 1996, the GNAT compiler is not yet fully mature in its support for complex real-time systems, but rapid progress is being achieved.

PREVIOUS PAGECONTENTSNEXT