HP OpenVMS Systems

This chapter covers the following topics:

• Lexical elements
• Run-time systems issues
• Mixed-language programming
• Compiler performance
• Implementation-dependent characteristics

In DEC Ada on OpenVMS and on DIGITAL UNIX systems, each graphic character corresponds to a unique code of the ISO standard 8859/1, commonly known as Latin--1. This character set contains 256 values.

The characters included in each of the categories of basic graphic characters are the ISO seven-bit characters plus additional characters. The effect is to allow the use of the additional uppercase and lowercase characters in forming identifiers and to allow the use of all the additional graphic characters in forming character literals and string literals.

By implementing characters as the ISO Latin--1 character set, DEC Ada also allows the additional 96 characters afforded by the eight-bit representation.

The characters allowed in the text of a program are the graphic characters and format effectors. The characters allowed in comments are the graphic characters, the escape character, and the horizontal tabulation character. DEC Ada does not provide pragmas or other means for locally defining the graphic characters used in identifiers and string literals.

The maximum number of characters allowed in a source line is 255. This also limits the length of identifiers to 255 characters.

The broken bar is not allowed as a replacement for the vertical bar.

10.2 Run-Time System Issues

The following sections describe a variety of implementation details that have an effect at run time.

10.2.1 Inclusion of the Run-Time Library with the Product Kit

Generally on OpenVMS systems, a DEC Ada Run-Time Library (SYS$SHARE:ADARTL.EXE) is included in the DEC Ada kit. DIGITAL supplies a run-time library (RTL) with necessary bug fixes beyond the RTL supplied by the operating system. A DEC Ada RTL is not always part of the kit. This has the following implications:

• The RTL shipped with the DEC Ada product supersedes the version that is bundled with the operating system. Therefore, when a new version of the OpenVMS operating system is installed, DEC Ada should be reinstalled.
• DEC Ada images that were created with previous versions of DEC Ada continue to run. In other words, programs created with previous versions of DEC Ada work with the new run-time library.
• Images created with DEC Ada run only on systems on which the DEC Ada Run-Time Library or a copy of the library has been installed. New DEC Ada programs require the new run-time library.

A subheap is allocated for each collection associated with an access type. Fixed-size blocks with bit-map allocation techniques are used for access types whose denoted type is fixed-size, and variable-length blocks with first-fit allocation techniques are used for access types whose denoted type is not fixed-sized.

Collections are deallocated when the scope of the parent access type is left. The predefined generic procedure UNCHECKED_DEALLOCATION is supported. Automatic garbage collection within a subheap is not provided.

10.2.3 Subprogam Call Parameter Handling

Parameter-passing and result mechanisms are chosen based on the types of parameters and the language specified. In addition, the user can specify a nondefault mechanism for parameters and results. Optional compiler-generated compilation notes report on the mechanisms chosen.

Within a DEC Ada program, the conventions used are much like those for a mixed-language program with language Ada specified.

For Ada programs, arrays and records are passed by reference except in circumstances where a byte-aligned copy of a record is required (for bit-aligned components of arrays and records, for example).

The allocation rules of the compiler are such that a record can be bit-aligned (not byte-aligned) only when its size is static and less than 32 bits (on OpenVMS VAX and ULTRIX systems) or 64 bits (on OpenVMS Alpha and DIGITAL UNIX systems). Therefore, copying of record values for the purposes of parameter passing is never an expensive operation.

Function results that fit in a register are generally returned in a register. For other cases involving fixed-size function results, the caller or callee generally allocates storage for the result and the address or a descriptor is passed as an additional parameter.

10.3 Mixed-Language Programming

To write mixed-language programs in any environment, the following topics need to be understood:

• Parameter passing
• Function results returned
• Data sharing
• Semantic rules for subprogram calls
• Data representation in the languages involved
• Detailed syntax and usage rules for the DEC Ada pragmas that support mixed-language programming

In general, all systems support the same interfaces for mixed-language programming. However, when mixing code from different programming languages, consider the following:

• On VAX systems, C expects data to be byte aligned.
  On Alpha systems, C expects data to be naturally aligned.
• On Alpha systems, Fortran complex data is returned by a mechanism that is not available in DEC Ada. There is no analogous restriction on passing complex data.
• The interface languages supported are ADA, C, BLISS, and FORTRAN. On OpenVMS systems, DEFAULT is also supported, which corresponds to the OpenVMS calling standard.
• The pragmas IMPORT_EXCEPTION, EXPORT_EXCEPTION, and PSECT_OBJECT are supported only on OpenVMS systems. All other pragmas associated with mixed-language programming are supported on both systems.
• The VALUE mechanism causes the value of the actual parameter or function result to be passed or returned. All Ada types can be used with the VALUE mechanism except unconstrained arrays and records. However, on VAX systems, the type or subtype must have a compilation size of 32 bits or less. On Alpha systems, the type or subtype must have a compilation size of 64 bits or less.
• The mechanism DESCRIPTOR is supported on OpenVMS systems only. It is not supported on DIGITAL UNIX systems, as those descriptors have only 32 bits available for an address. Instead, dope vectors are used. (However, you cannot specify the mechanism dope vectors.)
• The first optional parameter option for the pragmas IMPORT_FUNCTION and IMPORT_PROCEDURE is supported on VAX systems only.
• In mixed-language programs, termination of Ada tasks takes place according to the usual rules. For example, termination of a non-Ada main program waits for the termination of any Ada subprograms that involve tasks.

10.4 User Interface

DEC Ada source files are compiled and linked on the host system in the context of one or more program libraries, which are managed by the DEC Ada program library manager. This context defines where the results of a compilation are stored and which previously compiled units are considered in subsequent operations.

A DEC Ada program library is a dedicated directory that contains a set of files for each compilation unit successfully processed. The compiler and program library manager use that set of files to maintain information about the compilation unit.

When the program library context contains multiple libraries, DEC Ada views these libraries as an ordered list. This ordered list, together with the library search rules used by the compiler and program library manager, identifies which previously compiled units are considered and which library to modify with the results of the compilation or program library manager operation.

DEC Ada program libraries can be organized to suit the needs of any project. Features are provided that allow projects to perform the following:

• To use multiple libraries to isolate development
  In a single library environment, every time a compilation unit is compiled, it is redefined in its program library and the previous version is discarded. Multiple libraries let you compile units in private libraries without affecting any previous versions of units in project libraries. Libraries can be organized to isolate development of any of the following:
  • Different software components
  • Different versions of a software component
  • Work done by individual programmers or teams
• To layer less stable versions of a unit on top of more stable versions
  When a DEC Ada command that searches for units is entered, units are visible in a fashion similar to multiple panes of glass. The units in the first library identified by the context appear on the top pane, units in the second library appear on the second pane, units in the third library appear on a third pane, and so on. Therefore, units by the same name hide each other such that a unit in a subsequent library is hidden (made not visible) by a unit of the same name in a closer library. The search for a unit begins with the closest pane of glass (the first library identified in the ordered list) and follows through the subsequent panes until the unit is found.
• To quickly and easily configure and reconfigure libraries
  The DEC Ada program library manager provides a library specification syntax, which allows libraries to be configured and reconfigured using as little as a single command. This lets users easily change the configuration of libraries. In addition, individual programmers can establish different views of program library relationships without affecting the relationships defined in the libraries themselves or by other programmers.

For references that will provide more information about working with libraries and with the DEC Ada program library manager, see Appendix A, Table A-1.

10.5 Compiler Performance

There is no simple way to indicate the DEC Ada compilation rate because there are no accepted standards for this measure. Package specifications, which typically involve little or no code generation, tend to compile quickly. On the other hand, extensive use of generics and inline expansion can greatly slow the compilation rate. The compiler performs better on larger compilation units than on small ones. In addition, compiler performance improves if you follow these guidelines:

• Specify multiple files with a compilation command (the ADA command on OpenVMS systems; the ada command on DIGITAL UNIX or ULTRIX systems).
• Use either the ACS COMPILE (OpenVMS systems), ACS RECOMPILE (OpenVMS systems), or amake (DIGITAL UNIX or ULTRIX systems) command to compile obsolete units of a program.

DEC Ada provides several features and capabilities that specifically support the development of large Ada programs. These features and capabilities are licensed separately under the Professional Development Option (PDO). The PDO includes the following features:

• Smart recompilation
  This feature can significantly reduce the number of recompilations that are needed to rebuild a program after some compilation units change. Smart recompilation allows the compiler to propagate changes quickly through a system, eliminating up to 100% of the usual recompilations.
• Program library file-block caching
  This feature minimizes the actual amount of disk input-output that must be performed by using an in-memory cache of file blocks from the .acu files. As a result of file-block caching, the elapsed time for compilations is significantly reduced.
• Quick link (DIGITAL UNIX systems only)
  During incremental program development, this feature can significantly reduce the time to relink a large DEC Ada program after changes to a small number of program units.

To write DEC Ada programs that compile and execute efficiently, it is important to be aware of certain compiler and language features that can affect code size, as well as program compilation and execution times.

10.5.1 Compiler Optimizations

The DEC Ada compiler performs a number of standard optimizations to improve the quality of the generated code. The following is a list of these optimizations:

• Elimination of some common subexpressions
• Strength reduction in loops
• Code hoisting from structured statements, including the removal of invariant computations from loops
• Inline code expansion for many predefined operations
• Rearranging of unary minus and not operations to eliminate unary negation/complement operations
• Partial evaluation of logical expressions
• Global assignment of variables to registers
• Forward propagation of constant values
• Reordering of the evaluation of expressions to minimize the number of temporary values required
• Peephole optimization of instruction sequences
• Instruction scheduling (on Alpha systems)

In addition, the compiler performs the following Ada-specific optimizations:

• Elimination of redundant constraint checks
• Evaluation of all static subexpressions, even when evaluation is not required by the language
• Evaluation of other compile-time constant expressions that may not be considered static expressions in the language
• Elimination of dead code
• Elimination of redundant bounds checking of arrays in array subscripting and slicing
• Elimination of redundant address evaluations

Optimization is controlled at the command-line level. However, the user interface to each system is different. The relevant documentation must be consulted to determine which qualifier or option to specify.

Subprograms that are declared in a package but not used are loaded with the package.

In statements such as the following, the address of A(I) is evaluated only once:

A(I) := A(I) + 1;

With matrix computations like the following, the address calculation for A(I,J) is optimized:

for I in 1 .. N loop
   for J in 1 .. M loop
      A(I,J) ...
   end loop;
end loop;

10.5.2 Improving Performance with Pragma INLINE

• Explicitly. A subprogram is declared to be expanded inline. Inline expansion occurs each time the subprogram is called.
• Implicitly. The compiler automatically expands subprogram bodies inline under certain conditions.

The pragma INLINE is supported in most cases. Routines may not be expanded inline at the place of a call if they contain the following:

• Nested routine declarations
• Package bodies
• Exception declarations
• Generic declarations and/or instantiations
• Task declarations
• Dependent tasks
• Array or record type declarations
• Access type declarations
• Directly recursive calls

The result of instantiating a generic subprogram is also inlinable under the same conditions.

The compiler expands local routines inline without the pragma INLINE being specified where heuristics indicate that the size of the expanded call will be approximately the same as the call it replaces (or only a little larger). This inline expansion can be suppressed with the appropriate optimization option.

10.5.3 Improving Performance of Programs Using Generics

DEC Ada offers a number of features to improve the compilation time and performance of programs that use generics. For example:

• The pragmas INLINE_GENERIC and SHARE_GENERIC can be used to control how code is generated for generics. A number of equivalent /OPTIMIZE compilation qualifier options can also be used.
• The predefined library-level instantiations provided for commonly used generics (LONG_FLOAT_TEXT_IO, LONG_FLOAT_MATH_LIB and so on) can be used.

There is a relatively small and fixed overhead associated with locating and opening the program library file for each unit named in a with clause (independent of the size of that library unit). Also, for each library unit, it is necessary to transitively locate and open the program library file for each unit named in its with clauses. The occurrence of a unit in a with clause, of itself, has only this small initial overhead. Thereafter, additional incremental cost is incurred whenever needed information is first loaded from that unit.

For subunits, there is overhead required for locating and loading information about each ancestor unit up to and including the parent library unit, after which compilation proceeds at a rate comparable to any other unit.

Compilation performance is highly dependent upon the amount of physical memory present.

If the system does not have sufficient physical memory, the compiler pages excessively and the compilation speed is slowed considerably. However, all supported processors can be configured with enough memory so that there is a high limit on the size of a program unit that can be compiled.

There are no specific restrictions on the numbers of items of various kinds in a unit (identifiers, strings, nesting, and so on).

Tasks that are acting as monitors are not recognized as such and do not result in special code generation.

Predefined input-output packages are implemented using asynchronous techniques so that other tasks can execute while one task is waiting for input-output to complete.

On OpenVMS systems, the run-time libraries are shareable, which means that a single copy of library is used by all executing Ada programs on a particular system. The DEC Ada library is also used by the Ada compiler.

On DIGITAL UNIX systems, the run-time libraries can be either shareable or nonshareable.

On DIGITAL UNIX or on ULTRIX systems, when an Ada program is linked with a nonshareable run-time library, the size of the run-time system depends on which language features are used by the Ada program. For example, code to support tasking is not loaded for nontasking programs. Therefore, the size of the run-time system for nontasking programs will be smaller than in tasking programs.

10.6 Implementation-Dependent Characteristics

The DEC Ada compiler supports address representation clauses for objects and imported subprograms but does not support address representation clauses for packages or tasks. The compiler supports address representation clauses for entries as follows:

• On VAX systems, entries for address representation clauses are not supported.
• On DIGITAL UNIX systems, entries for address representation clauses are supported to allow some DIGITAL UNIX signals to be associated with task entry calls. For more information, see Section 4.5.

The DEC Ada compiler provides additional constant declarations in the predefined package SYSTEM as shown in Table 10-1.

The value of the constant LARGEST_INTEGER is a range of MIN_INT .. MAX_INT.

SYSTEM.TICK represents the smallest unit of time used by the operating system in its time-related system services. Table 10-2 table shows the value of the system-dependent named number SYSTEM.TICK.

The following table lists implementation limits for DEC Ada.