HP OpenVMS Systems

On OpenVMS (VAX and Alpha) and DIGITAL UNIX systems, DEC Ada provides the following strongly typed bindings:

• X Window System Version 11R4 and Motif Version 1.1.3
• X Window System Version 11R5 and Motif Version 1.2

On DIGITAL UNIX systems, DEC Ada also provides the strongly typed binding X Window System Version 11R6. This is the default on DIGITAL UNIX systems.

On DIGITAL UNIX, DEC Ada also provides support for the POSIX Ada Language Interface bindings as required by IEEE Standard 1003.5-1992 (IEEE Standard for Information Technology, POSIX Ada Language Interfaces).

On ULTRIX systems, DEC Ada provides the strongly typed binding X Window System Version 11R4.

The DEC Ada compiler is a traditional, multipass, optimizing compiler. It uses many proprietary internal data structures. No attempt was made to avoid any particular Ada language constructs.

The intermediate representations used by the compiler are an abstract syntax tree and a code generator intermediate language.

The format of the final object program is a standard object file that can be linked on the host system. The source file for each unit is fully identified in the object file. This information is used by both the program library manager and by the debugger.

Information can be communicated to a DEC Ada program with command-line arguments and file or interactive input-output. On OpenVMS systems, information can be communicated with system-specific features such as logical names, global sections, and mailboxes. On DIGITAL UNIX systems, information can be communicated with system-specific features such as environment variables, shared memory segments, semaphore, pipes, fifos, and sockets.

7.1 Program Library Management

The program library manager provides management and utility functions for program libraries. The program library manager is invoked by DEC Ada commands, which can be entered in the form of one-line commands.

The program library management commands and their resulting actions are identical on OpenVMS VAX and OpenVMS Alpha systems. Similar commands are available on DIGITAL UNIX systems.

When linking an Ada program, the program library manager identifies the units that are needed and checks that they are all current. It also constructs an initialization module that elaborates the library units in an appropriate order. Finally, it invokes the linker to form an executable program.

A DEC Ada program executable is run from the system prompt.

On OpenVMS systems when a program library is created, the following default system characteristics are in effect:

• FLOAT_REPRESENTATION = VAX_FLOAT
• LONG_FLOAT = G_FLOAT
• MEMORY_SIZE = 2147483647
• SYSTEM_NAME = VAX_VMS or OpenVMS_AXP

On DIGITAL UNIX systems when a program library is created, the following default system characteristics are in effect:

• FLOAT_REPRESENTATION = IEEE_FLOAT
• MEMORY_SIZE = 9223372036854775807
• SYSTEM_NAME = DEC_OSF1_AXP

The value of SYSTEM_NAME does not cause the compiled code to differ. It is used to determine target-related compilation unit dependences. Target-related compilation unit dependences can occur in Ada code in the following cases:

• Use of SYSTEM_NAME causes a VAX_VMS, OpenVMS_AXP, or DEC_OSF1_AXP dependence.
• Use of the pragma TIME_SLICE causes a VAX_VMS dependence.
• Use of the pragma AST_ENTRY or the AST_ENTRY attribute causes a VAX_VMS or an OpenVMS_AXP dependence.
• Use of any of the relative or indexed input-output packages causes a VAX_VMS or an OpenVMS_AXP dependence.

All compiler construction tools are proprietary to Digital Equipment Corporation.

7.1.1 Program Library Units

DEC Ada permits a program library unit to be used as a main program under the following conditions:

• Procedures with no formal parameters
  On OpenVMS systems, the status returned to the OpenVMS environment upon normal completion of the procedure is the value 1.
  On DIGITAL UNIX systems, the status returned to the DIGITAL UNIX environment upon normal completion of the procedure is the value 0.
  On DIGITAL UNIX systems, the status returned to the DIGITAL UNIX environment when unhandled exceptions have been raised is the value 42.
• Functions (with no formal parameters) whose returned value is of a discrete type
  In this case, the status returned to the operating system environment upon normal completion of the function is the function value.
• Procedures declared with the pragma EXPORT_VALUED_PROCEDURE and having one formal out parameter that is of a discrete type
  In this case, the value returned to the operating system environment upon normal completion of the procedure is the value of the first (and only) parameter.

When a main function or a main procedure declared with the pragma EXPORT_VALUED_PROCEDURE returns a discrete value whose size is less than 32 bits (on VAX) or 64 bits (on OpenVMS Alpha and DIGITAL UNIX), the value is zero- or sign-extended as appropriate.

7.1.2 Compilation Management

There are several ways of managing compilation. For example, recompilation of an entire program can be managed automatically by specifying one of the following commands with the main subprogram:

• On OpenVMS systems, ACS RECOMPILE
• On DIGITAL UNIX systems, amake

Recompilation of an entire program can be managed by forcing certain units to be considered obsolete. To do this, specify one of the following commands:

• On OpenVMS systems, ACS [RE]COMPILE/OBSOLETE=unit
• On DIGITAL UNIX systems, amake -x unit

On OpenVMS systems, DEC Ada provides several features (such as sublibraries and library search paths), that help the user work with multiple program libraries. Also, DEC Ada provides the commands listed in Table 7-1.

On DIGITAL UNIX systems, DEC Ada provides program library contexts to work with multiple program libraries. (DEC Ada program library contexts are similar to DEC Ada library search paths.)

Note that program libraries cannot be mixed across targets.

Table 7-1 shows the program library commands that aid in working with multiple program libraries.

The program library manager provides management and utility functions for program libraries. The program library manager is invoked by DEC Ada commands, which can be entered in the form of one-line commands.

Table 7-2 summarizes the program library management commands on OpenVMS and DIGITAL UNIX systems.

When compiling DEC Ada programs, the following compilation options are available.

Smart Recompilation

Smart recompilation is a feature that significantly reduces the time needed to compile a modified program to make it current again. Smart recompilation reduces compilation time by minimizing the effects of source code changes on dependent units and by avoiding the recompilation of dependent units that are not affected by the changes.

This option is available on OpenVMS and DIGITAL UNIX systems only when the separate DEC Ada Professional Development Option license is enabled.

Quick Link

Quick link is a feature that reduces the time required to link an Ada program during incremental program development.

This option is available on DIGITAL UNIX systems only when the separate DEC Ada Professional Development Option license is enabled.

Partial Compilation

Partial compilation allows units to be added to the library without consideration as to compilation order. During partial compilation, the syntax of units is checked and information about unit dependences is stored. Because syntax-checked units are considered obsolete, they must be fully compiled before linking. Invoking a subsequent compilation command makes a unit current and generates the necessary code for linking. For example on OpenVMS systems, the following provides a syntax-checked compilation:

ACS LOAD *.ADA

On DIGITAL UNIX systems, the following provides a syntax-checked compilation:

ada -y *.ada

Program Design Support

Ada source code can be processed as a detailed program design. This design checking capability checks for internal consistency of complete or partially written programs, but it does not fully compile the program.

The Program Design Facility (PDF), a DECset utility, provides many features in support of program design through hooks in the LSE editor.

Generics

By default, the DEC Ada compiler creates a generic instantiation by expanding the corresponding generic body using the appropriate actual types. The expansion is done inline at the point of the instantiation when the implementation-defined pragma INLINE_GENERIC or equivalent optimization options are in effect at compile time.

On OpenVMS VAX systems, shareable code is generated for a generic instantiation if the implementation-defined pragma SHARE_GENERIC or equivalent /OPTIMIZE compilation qualifier options are in effect at compile time. Even if shareable code is not generated for an instance, the instance tries to share code that resulted from a previous instance to which the pragma SHARE_GENERIC (or equivalent) applied.

Costs over and above an equivalent, nongeneric subprogram or package are negligible. For an in formal object, a constant is created for each instantiation and initialized from the appropriate expression. For an in out formal object, temporary locations can be needed as for the equivalent renaming. The code for the resulting subprogram or package is compiled and optimized in the presence of full compile time information about the actual parameters.

Inline Expansion of Generics

Several options are provided to cause the compiler to automatically expand generics inline under certain conditions.

DEC Ada provides the pragma INLINE_GENERIC to direct the compiler to attempt inline expansion of the body created for each instantiation of the named generic declarations or for the particular named instance.

If the pragma INLINE_GENERIC is applied to a generic instantiation (either by naming the instantiation or by naming the generic declaration from which the instantiation was derived), the generic is inlined only if the corresponding generic body is compiled before the instantiation. In such a case, inline inclusion creates a dependence of the instantiation on the generic body, and the compiler recognizes this dependence when deciding on the need for recompilation. If an instantiation is compiled before the generic body, the pragma is ignored and a diagnostic message that inline inclusion was not achieved is issued.

DEC Ada does not require that a generic declaration and the corresponding proper body be part of the same compilation, nor does DEC Ada require that the subunits of a generic unit be part of the same compilation. The instantiation of a generic declaration before the corresponding body is available results in an incomplete compilation.

On OpenVMS VAX systems, DEC Ada provides the pragma SHARE_GENERIC to direct the compiler to attempt sharing of the code generated for each instantiation of the named generic declarations or for the particular named instances.

The pragmas SHARE_GENERIC and INLINE_GENERIC cannot apply to the same generic declaration. However, the pragma INLINE_GENERIC can be specified for an instance even if the pragma SHARE_GENERIC applies to the corresponding generic declaration. In this case, the pragma specified for the instance overrides the pragma that applies to the generic declaration, and the expansion of the particular instance is expanded inline. Similarly, the pragma SHARE_GENERIC can be specified for an instance even if the pragma INLINE_GENERIC applies to the corresponding generic declaration. Again, the pragma specified for the instance overrides the pragma that applies to the generic declaration.

Maximal Inline Expansion of Subprograms

Several options are provided to allow implicit inline expansion of some small subprograms within a unit or declared by other units. These options cause the compiler to assume a pragma INLINE for any subprogram if it improves execution speed and reduces code size.

Generic Code Sharing

On VAX systems, several options are provided to allow sharing of the code generated for the instantiations of a generic package or subprogram.

Debugging Information

Several options are provided to control the amount of debugging information that is included in the object file. These options include: none , traceback (subset) , and full .

Code Optimization

Several options are provided to control the level of optimization that is applied in producing the compiled code.

Compilation and Recompilation Impact

Several options are provided to determine the impact of compilation and recompilation without actually doing the compilation. These options are useful for performing what-if analysis on units when the compilation order of a program has not changed.

Error Limits

This option controls the number of errors that are accepted before the compilation of a unit is terminated.

Listing Output Control

Several options and symbols are provided to control listing output. When in effect, some of the following options and symbols cause additional information to be included in the listing file:

• Header lines
  The header lines of each listing page identify the name of the unit being compiled, the date and time of the compilation, the compiler version, the full name of the source file being compiled, the date and time that the file was created or last modified, and any title or subtitle text specified with the implementation-defined pragma TITLE.
  When there is more than one input file, a separate listing file is produced for input file.
• Messages
  Messages are embedded in the listing at the point where they apply. A total of each class of messages (errors, warnings, and informationals) is given at the end of the listing.
• Machine code
  On OpenVMS systems, the /MACHINE_CODE qualifier can be used to cause the generated machine code to be included in the listing. On DIGITAL UNIX and ULTRIX systems, the ADALISFLAGS environment variable can be used. The code appears following each complete subprogram or body. The machine code is correlated with the originating source line.
• Type or data information
  No type map or data map display is available in the listing. No cross-reference option is available in listings. However, cross-reference information can be obtained with a source code analyzer or, on DIGITAL UNIX, the DEC FUSE Cross Referencer. For more information, see Table 1-1.
• Portability summary
  A portability summary is included by default in each listing file. This summary lists the use of certain potentially nonportable constructs in the Ada program. For more information, see Section 11.1.
• Compiler statistics
  The final page of the listing displays various compiler statistics. CPU time, elapsed time, page faults, and input-output counts are provided for each phase (or subphase) of compilation. Total information is also provided including CPU time, elapsed time, lines-per-minute compilation rate (based on CPU time), and space (virtual pages) used. There are no fixed-size tables in the compiler.

Other options and symbols cause specialized files to be created and determine where to write these files.

7.4 Exceptions

Exceptions are handled as follows:

• On OpenVMS systems, exception handling is implemented using the OpenVMS condition-handling mechanism.
• On ULTRIX systems, exception handling is implemented using the routines and data structures provided in the ULTRIX header file exception.h.
• On DIGITAL UNIX systems, exception handling is implemented in accordance with the DIGITAL UNIX calling standard.

On OpenVMS and on DIGITAL UNIX systems, the package CURRENT_EXCEPTION is implemented.

DEC Ada provides predefined exceptions in the package STANDARD.IO_EXCEPTIONS and SYSTEM. DEC Ada also allows user-defined exceptions to anticipate and handle more specific errors than those covered by the predefined exceptions.

In accordance with the language definition, DEC Ada provides a set of run-time checks that underlie the predefined exceptions.

Provision of an Ada exception handler affects optimization but has no direct cost if no exceptions occur. When exceptions occur, there are increasing amounts of overhead as the following options are exercised:

• Provision of an exception part
• Number of handlers in that part
• Use of raise statements

Exceptions are defined by the address of the location where the text of the exception is stored. Certain exceptions (for example, integer overflow) are automatically mapped to the predefined Ada exceptions (for example, CONSTRAINT_ERROR).

The predefined exception CONSTRAINT_ERROR is raised as required by the execution of a predefined numeric operation that cannot deliver a correct result (within the declared accuracy for real types). It is raised for integer overflow, floating-point overflow, and integer and floating-point division by zero. It is not raised by floating-point underflow (the value zero results).

On OpenVMS systems, underflow can be handled as an imported OpenVMS condition.

CONSTRAINT_ERROR is also raised in a few additional cases related to implementation-defined features.

DEC Ada raises the exception NUMERIC_ERROR only when it is explicitly raised with a raise statement. Wherever the standard requires that NUMERIC_ERROR be raised, the exception CONSTRAINT_ERROR is raised instead.

This difference from the standard is endorsed by both the ANSI and ISO groups and is documented as an Ada language interpretation stating that wherever the Standard requires the NUMERIC_ERROR be raised (other than by a raise statement), CONSTRAINT_ERROR should be raised instead. This interpretation is non-binding.

The predefined exception PROGRAM_ERROR is raised as required. It is also raised in a few instances that are not required. It is not raised for incorrect order dependences.

DEC Ada defines the exception NON_ADA_ERROR (in the package SYSTEM).

DEC Ada provides the predefined package of input-output exceptions, IO_EXCEPTIONS. On OpenVMS systems, DEC Ada provides an additional package of input-output exceptions (AUX_IO_EXCEPTIONS) for use with the relative and indexed input-output packages.

The predefined exceptions STORAGE_ERROR and TASKING_ERROR are raised as required.

The predefined pragma SUPPRESS is supported.

In addition, the implementation-defined pragma SUPPRESS_ALL provides the ability to suppress all run-time checking in a compilation unit. The pragma SUPPRESS_ALL is allowed only following a compilation unit. The scope of the pragma is the entire unit or subunit that it follows. In DEC Ada, the pragma SUPPRESS_ALL does not suppress some checks that are always performed by the hardware and run-time system. For example, the checks DIVISION_CHECK and OVERFLOW_CHECK correspond to hardware checks that cannot be suppressed on OpenVMS systems. The exceptions that correspond to the checks ACCESS_CHECK and STORAGE_CHECK can also be raised when the pragma SUPPRESS_ALL is in effect.

On OpenVMS systems, DEC Ada provides the following mechanisms for handling system conditions or exported Ada exceptions:

• Pragma IMPORT_EXCEPTION, which allows Ada exception handlers to handle any OpenVMS conditions raised in DEC Ada code or in imported (non-Ada) code
• Package CONDITION_HANDLING, which allows additional control over OpenVMS condition handling
• Pragma EXPORT_EXCEPTION, which allows handlers written in other languages to handle exported Ada exceptions

When non-Ada code is imported in an Ada program, hardware conditions or exceptions that may be signaled can be handled by an others choice in the Ada frame that calls the non-Ada routines.

Both the exception choice others and the predefined exception NON_ADA_ERROR can be used to handle DIGITAL UNIX signals. If a user-defined signal handler is used, it can interfere with Ada exception handling and adversely affect the behavior of the program.

DEC Ada allows certain ULTRIX and DIGITAL UNIX signals to be handled from an Ada program. For example, some signals are treated as being equivalent to certain predefined Ada exceptions. When one of these is signaled during the execution of an Ada program, the effect is as if the predefined exception were raised, and the signal can be caught by an Ada exception handler that exists to catch the predefined exception.