[Ada Information Clearinghouse]

Ada '83 Quality and Style:

Guidelines for Professional Programmers

Copyright 1989, 1991,1992 Software Productivity Consortium, Inc., Herndon, Virginia.

CHAPTER 7: Portability

Discussions concerning portability usually concentrate on the differences in computer systems. But the development and runtime environment may also change:
portability (software). The ease with which software can be transferred from
one computer system or environment to another (IEEE Dictionary 1984).
And most portability problems are not pure language issues. Portability involves hardware (byte order, device IO); software (utility libraries, operating systems, runtime libraries). This section will not address these challenging design issues.

This section does identify the more common portability problems that are specific to Ada when moving from one platform or compiler to another. It also suggests ways that non-portable code can be isolated. By using the implementation hiding features of Ada, the cost of porting can be significantly reduced.

In fact, many language portability issues are solved by the strict definition of the Ada language itself. In most programming languages, different dialects are prevalent as vendors extend or dilute a language for various reasons: conformance to a programming environment; or features for a particular application domain. The Ada Compiler Validation Capability (ACVC) was developed by the U.S. Department of Defense at the Ada Validation Facility, ASD/SIDL, Wright-Patterson Air Force Base to ensure that implementors strictly adhered to the Ada standard.

As part of the strict definition of Ada, certain constructs are defined to be erroneous and the effect of executing an erroneous construct is unpredictable. Therefore erroneous constructs are obviously not portable. Erroneous constructs are discussed in Guideline 5.9, and are not repeated in this chapter.

Most programmers new to the language expect Ada to eliminate all portability problems; it definitely does not. Certain areas of Ada are not yet covered by validation. The definition of Ada leave certain details to the implementor. The compiler implementor's choices with respect to these details affect portability.

There are some general principles to enhancing portability exemplified by many of the guidelines in this chapter. They are:

These guidelines cannot be applied thoughtlessly. Many of them involve a detailed understanding of the Ada model and its implementation. In many cases, you will have to make carefully considered tradeoffs between efficiency and portability. Reading this chapter should improve your insight into the tradeoffs involved.

The material in this chapter was largely acquired from three sources: the Ada Run Time Environment Working Group (ARTEWG) Catalogue of Ada Run Time Implementation Dependencies (ARTEWG 1986); the Nissen and Wallis book on Portability and Style in Ada (Nissen and Wallis 1984); and a paper written for the U.S. Air Force by SofTech on Ada Portability Guidelines (Pappas 1985). The last of these sources (Pappas 1985) encompasses the other two and provides an in depth explanation of the issues, numerous examples, and techniques for minimizing portability problems. Conti (1987) is a valuable reference for understanding the latitude allowed for implementors of Ada and the criteria often used to make decisions.

This chapter's purpose is to provide a summary of portability issues in the guideline format of this book. The chapter does not include all issues identified in the references, but only the most significant. For an in-depth presentation, see Pappas (1985). A few additional guidelines are presented here and others are elaborated upon where applicable. For further reading on Ada I/O portability issues, see Matthews (1987), Griest (1989), and CECOM (1989).

Some of the guidelines in this chapter cross reference and place stricter constraints on other guidelines in this book. These constraints apply when portability is being emphasized.

In this chapter...

7.1 Fundamentals
7.1.1 Global Assumptions
7.1.2 Actual Limits
7.1.4 Main Subprogram
7.1.5 Encapsulating Implementation Dependencies
7.1.6 Implementation-Added Features

7.2 Numeric Types and Expressions
7.2.1 Predefined Numeric Types
7.2.2 Ada Model
7.2.3 Analysis
7.2.4 Accuracy Constraints
7.2.6 Precision of Constants
7.2.7 Subexpression Evaluation
7.2.8 Relational Tests

7.3 Storage Control
7.3.1 Representation Clause

7.4 Tasking
7.4.1 Task Activation Order
7.4.2 Delay Statements
7.4.3 Package Calendar, Type Duration, and System.Tick
7.4.4 Select Statement Evaluation Order
7.4.5 Task Scheduling Algorithm
7.4.6 Abort
7.4.7 Shared Variables and Pragma Shared

7.5 Exceptions
7.5.1 Predefined Exceptions
7.5.2 Constraint_Error and Numeric_Error
7.5.3 Implementation-Defined Exceptions

7.6 Representation Clauses And Implementation-Dependent Features
7.6.1 Representation Clauses
7.6.2 Package System
7.6.3 Machine Code Inserts
7.6.4 Interfacing Foreign Languages
7.6.5 Implementation-Defined Pragmas and Attributes
7.6.6 Unchecked Deallocation
7.6.7 Unchecked Conversion
7.6.8 Run Time Dependencies

7.7 Input/Output
7.7.1 Name and Form Parameters
7.7.2 File Closing
7.7.3 I/O on Access Types
7.7.4 Package Low_Level_IO

numeric types and expressions
storage control
representation clauses and implementation-dependent features

Back to document index