HP OpenVMS Systems

When working with multiple targets or considering a port between platforms, it is important to know which parts of the code are target-specific and which are target-dependent and how big an effect a change in the target can have. The following sections discuss topics related to program portability and target dependence.

11.1 Determining DEC Ada Program Portability

On OpenVMS systems to determine if a DEC Ada program uses certain potentially nonportable features, use the /SHOW=PORTABILITY qualifier with any of the following DEC Ada compilation commands:

• DCL ADA
• ACS COMPILE
• ACS RECOMPILE

The /SHOW=PORTABILITY qualifier (which is the default for all of the compilation commands) causes the compiler to include a portability summary in the compilation listing file. (The /LIST qualifier must also be specified.)

On DIGITAL UNIX systems, use a "p" in the ADALISFLAGS environment variable to cause a portability summary to be included with the compilation listing file with any of the following DEC Ada compilation commands:

• ada
• amake

The -v switch must also be specified with these commands.

The following sections discuss the factors affecting the portability of a DEC Ada program and identify those features that may appear in the portability summary.

11.2 Factors Affecting Portability

A program's portability depends on the set of available implementations that are appropriate for the program. For example, the Ada standard does not specify the range of digits for floating-point types that must be supported by an implementation.

If an implementation can support the requested accuracy and implied range, then the program should be portable with respect to that implementation. If the implementation cannot support the requested accuracy, then it will produce an error during compilation (rather than allowing the program to compile and then execute with unacceptable results). The use of an implicit underlying type---in this case, the DEC Ada predefined type LONG_FLOAT (and either a D-floating or G-floating representation)---is not relevant to whether or not the program is portable.

The explicit use of a predefined type, such as LONG_FLOAT, also may or may not be portable. For example:

type REAL is new LONG_FLOAT;

The fact that some other implementation may support a predefined type LONG_FLOAT (as described in the Ada standard) does not ensure that the program is portable to that implementation. In particular, the accuracy provided by that implementation may be less than the accuracy provided by DEC Ada---which may or may not be significant to the program. This can differ even on DEC Ada platforms.

The DEC Ada portability summary does not list implicit uses of the type LONG_FLOAT. It does list explicit uses of the type LONG_FLOAT.

The abstraction properties of the Ada language imply that even when a particular construct is defined by a nonportable construct, uses of that particular construct are not necessarily also nonportable. For example, an unchecked conversion from the INTEGER to the type ADDRESS could be implemented across a large number of Ada implementations in various ways. However, it is the conversion declaration, not the conversion call, that should be examined when porting a program that uses the conversion function.

Another example of this concept occurs in the DEC Ada implementation of the predefined package TEXT_IO. The private part of TEXT_IO's specification uses some implementation-defined pragmas, such as the pragma IMPORT_PROCEDURE. The package body uses even more nonportable constructs, such as the type ADDRESS, the implementation-defined attribute TYPE_CLASS, and other DEC Ada features. However, the portability of programs that use the package TEXT_IO is not compromised.

Another consideration is that pragmas (which, as required by the Ada standard, cannot affect the legality of a program) may or may not be relevant to a program's correct operation, portability, or both. For example, a program may work correctly only if the pragma SHARED is supported by an implementation or only if the pragma PRIORITY is supported with a certain range of priorities. For this reason, the portability summary shows the use of many of the language-defined pragmas as well as the use of all of the implementation-defined pragmas.

11.3 Features Listed in the Portability Summary

The portability summary lists one or more of the features or constructs shown in Table 11-1. The summary briefly describes the feature or construct and follows each description with the line numbers where the use of the feature or construct occurs. Features or constructs that are implementation-specific are marked with an asterisk (*). For example:

PORTABILITY SUMMARY
----------- -------
Source program elements which may effect porting this program to other
targets and the source line numbers where these elements were detected.
Please refer to the manual in ADA$EXAMPLES:DEC_ADA_OVERVIEW_AND_COMPARISON.*.


Type STANDARD.FLOAT defaults to F_FLOAT on OpenVMS and IEEE_*_FLOAT on UNIX
                96

Type STANDARD.LONG_FLOAT defaults to G_FLOAT on OpenVMS, and IEEE_DOUBLE_FLOAT
on DIGITAL UNIX
                97

Type STANDARD.LONG_LONG_FLOAT defaults to H_FLOAT on VAX, G_FLOAT on OpenVMS
Alpha, and IEEE_DOUBLE_FLOAT on UNIX
                98

Type STANDARD.LONG_INTEGER is 32 bits on VAX and 64 bits long on Alpha targets
                95

Predefined package SYSTEM contains entities which may not be implemented on
other targets
                92

Subtype SYSTEM.PRIORITY may vary on other non-DIGITAL Ada targets
               123   125

SYSTEM.INTEGER_*  integer types may not be portable to non-DIGITAL Ada targets*
               119   120   121

        where * indicates an implementation-defined feature

Italicized text is used in Table 11-1 to explain some of the features or constructs. The text does not appear in the actual portability summary.

The following sections discuss briefly the factors affecting portability between specific platforms. They include a table for each platform pair highlighting issues when porting and indicating where, in this guide, more information is located.

11.4.1 Porting from DEC Ada for OpenVMS VAX Systems to OpenVMS Alpha Systems

The 64-bit Alpha architecture provides many benefits, particularly in the areas of data representation, data access, and data alignment. However, porting from the 32-bit VAX architecture involves various issues. Table 11-2 highlights the portability issues with pointers to additional information in this guide and notes.