HP OpenVMS Systems

Table D-15 lists implementation limits for DEC Ada on DIGITAL UNIX systems.

This appendix compares DEC Ada on OpenVMS VAX and Alpha systems and GNAT for OpenVMS Alpha, including differences in the implementation or interpretation of the Ada standards.

The GNAT compiler is a high-quality, complete compiler for Ada95, integrated into the GCC compiler system and distributed with sources by Ada Core Technologies, Inc. DIGITAL recommends GNAT Professional, which is available with full support from:

• Ada Core Technologies, Inc.
• 73 Fifth Avenue, 11B, New York, NY 10003
• Tel: +1 212 620 7300
• Fax: +1 212 807 0162

Information is available at the following Web site:

http://www.gnat.com

In cases where the implementation of DEC Ada differs between OpenVMS Alpha systems and OpenVMS VAX systems, GNAT follows the Alpha implementation.

GNAT is an Ada 95 compiler, and DEC Ada is an Ada 83 compiler. Generally, Ada 95 is highly upwards compatible with Ada 83, so Ada 83 programs should run in Ada 95 with no changes or only minor changes. The Ada 95 Reference Manual (ANSI/ISO/IEC-8652:1995) provides details on known incompatibilities.

GNAT provides the qualifier /83 on the GNAT COMPILE command and the pragma ADA_83 to specify that GNAT should operate in Ada 83 mode. GNAT does not guarantee complete conformance to Ada 83 in this mode, but in practice use of this qualifier should eliminate most sources of incompatibilities. In particular, it eliminates the recognition of the additional Ada 95 keywords, allowing them to be used as identifiers, as in Ada 83. It also handles the cases of packages with optional bodies, and generics that instantiate unconstrained types without the use of angle brackets (< >).

E.1 Language-Related Features

The following sections highlight differences in types, representations of types, operations, alignment, and related topics.

E.1.1 Integer Types

DEC Ada (on both OpenVMS Alpha and OpenVMS VAX) and GNAT provide the predefined integer types shown in Table E-1.

DEC Ada has defined the following additional integer types:

• INTEGER_8
• INTEGER_16
• INTEGER_32
• INTEGER_64 for OpenVMS Alpha systems only
• LARGEST_INTEGER

With GNAT, you can get the first four of these types from the standard Ada 95 package INTERFACE. Alternatively, use the pragma EXTEND_SYSTEM, as described in Section E.3.

On DEC Ada for OpenVMS VAX systems, the maximum integer size is 32 bits; on DEC Ada for OpenVMS Alpha systems and on GNAT, the maximum integer size is 64 bits.

E.1.2 Floating-Point Numbers and Representations

Table E-2 lists the floating-point types provided by DEC Ada and declared in the package STANDARD. It also presents their default representations. The ones for Alpha systems apply to GNAT.

The predefined attributes that yield the characteristics of each floating-point type are described in the DEC Ada Language Reference Manual. Values of these attributes for the DEC Ada floating-point data representations are listed in Appendix F of that manual. The DEC Ada run-time reference manuals also give information on the internal representation of the DEC Ada floating-point types.

Defaults

On DEC Ada (for both OpenVMS VAX and OpenVMS Alpha) the default is VAX_FLOAT. On GNAT, the default is IEEE_FLOAT.

Pragmas FLOAT_REPRESENTATION and LONG_FLOAT

DEC Ada provides the pragma FLOAT_REPRESENTATION, which acts as a program library switch to allow control over the internal representation chosen for the predefined floating-point types declared in the packages STANDARD and SYSTEM.

On OpenVMS VAX systems, there is only one allowable value, which is the default, VAX_FLOAT. When the value VAX_FLOAT is specified, floating-point types are represented with the VAX hardware types F_floating, D_floating, G_floating, and H_floating. The type H_floating is available on OpenVMS VAX systems only.

On OpenVMS Alpha systems, the format of this pragma is as follows:

On OpenVMS Alpha systems, this pragma controls the representation of floating-point types as follows:

• If the value VAX_FLOAT is specified, then floating-point types are represented with the VAX hardware types F-floating, D-floating, G-floating, and H-floating. H-floating is available on OpenVMS VAX systems only.
  If the value is VAX_FLOAT, the default representation of the predefined type LONG_FLOAT is G-floating. The representation can be changed with the pragma LONG_FLOAT.
• If the value IEEE_FLOAT is specified, then floating-point types are represented with the IEEE single and double floating-point types.

On OpenVMS VAX systems, the predefined library is compiled with VAX_FLOAT.

On OpenVMS Alpha systems, the predefined library is compiled with VAX_FLOAT specified for the pragma FLOAT_REPRESENTATION, and VAX_FLOAT is required for interface to system routine calls. System service calls expect VAX floating-point format, not IEEE format. Therefore, it is not advisable to change the format of floating-point numbers passed to system calls. An explicit type conversion may be necessary to use the predefined library.

On GNAT, the pragma FLOAT_REPRESENTATION functions as a configuration pragma, as defined by Ada 95. Note that the concept of configuration pragma corresponds closely to the DEC Ada concept of program library qualifier.

The predefined libraries in GNAT are built using IEEE_FLOAT, so it is not advisable to change the format of numbers passed to standard library routines; explicit type conversions may be necessary. However, on GNAT, VAX_FLOAT can be useful in interfacing to existing code and data. There are two ways to specify VAX_FLOAT:

• If the requirement for the use of VAX_FLOAT is localized, then the best approach is to use the predefined VAX_FLOAT types in package SYSTEM, as extended by EXTEND_SYSTEM. For example, use SYSTEM.F-FLOAT to specify the 32-bit F-Float format.
• If an entire program depends heavily on the use of the VAX_FLOAT and assumes that the types in package Standard are in VAX_FLOAT format, then it may be desirable to reconfigure GNAT to assume VAX_FLOAT by default. This is done by using the GNAT LIBRARY command to rebuild the library, and then using the general form of the FLOAT_REPRESENTATION pragma to ensure that this default format is used throughout. The form of the GNAT LIBRARY command is:

  GNAT LIBRARY /CONFIG=<file> /CREATE=<directory>

  where <file> contains the new configuration pragmas and <directory> is the directory to be created to contain the new library.

DEC Ada and GNAT provide the pragma LONG_FLOAT to allow control over the internal representation chosen for the predefined type LONG_FLOAT and for floating-point type declarations with digits specified in the range 7 .. 15.

For this pragma to have an effect on OpenVMS systems, the pragma FLOAT_REPRESENTATION must also have a value of VAX_FLOAT (the only allowable value on an OpenVMS VAX system, which does not support IEEE_FLOAT). When the value of FLOAT_REPRESENTATION is VAX_FLOAT, the default representation of the type LONG_FLOAT is G_floating.

The format of this pragma on OpenVMS Alpha systems is as follows:

For more information, see Section 2.2.2 in this guide and the sections on the pragmas LONG_FLOAT and FLOAT_REPRESENTATION in the DEC Ada Language Reference Manual.

GNAT supports the pragmas FLOAT_REPRESENTATION and LONG_FLOAT. However, if they specify other than the default representation for types in STANDARD, the library must be rebuilt using GNAT LIBRARY. For more information, see the GNAT User's Guide.

The supported types and IEEE default representations are described in Table E-3:

LONG_LONG_FLOAT corresponds to the highest precision floating-point type supported by the hardware. On OpenVMS Alpha, this is the same as LONG_FLOAT.

E.1.3 Operations on Fixed-Point Types

In DEC Ada (unless the language specifies otherwise), the results of operations on fixed-point types are rounded away from zero for both positive and negative numbers. Therefore, +0.5 rounds to 1 and --0.5 rounds to --1.

On GNAT for OpenVMS Alpha, the results of operations on fixed-point types are in accordance with the Ada 95 rules. In particular, results of operations on decimal fixed-point types are truncated.

E.1.4 Record and Array Component Alignment

On DEC Ada for OpenVMS VAX, all noncomposite components are aligned on byte boundaries. Although the VAX hardware generally requires little alignment, alignment clauses can be useful in a mixed-language environment where you want to force objects to a particular boundary.

On DEC Ada for OpenVMS Alpha, all noncomposite components are aligned on natural boundaries. For example, 1-byte components are aligned on byte boundaries, 2-byte components on 2-byte boundaries, 4-byte components on 4-byte boundaries, and so on. The OpenVMS Alpha hardware runs more efficiently with naturally aligned data.

ON GNAT for OpenVMS Alpha, alignment rules are compatible with DEC Ada for OpenVMS Alpha.

E.1.5 Address Clauses and Access Types

In DEC Ada and GNAT, address clauses are supported for objects or imported subprograms.

The predefined type SYSTEM.ADDRESS is implemented in the DEC Ada compiler and GNAT compiler as a private type for which conventional addition, subtraction, and relational operations are provided. On OpenVMS systems, SYSTEM.ADDRESS and all access types are 32-bit types.

GNAT is compatible with DEC Ada in its handling of address clauses and access types, except for some limitations in the form of address clauses for composite objects with initialization. Such address clauses are easily replaced by the use of an explicitly defined constant. For example, the following sequence of declarations will be rejected by GNAT, because the address cannot be computed at the time that Q is declared:

X, Y : Integer := Init_Func;
Q : String (X .. Y) := "abc";
   .
   .
   .
for QAddress use Compute_Address;

To achieve the intended effect, write instead:

X, Y : Integer := Init_Func;
Q_Address : constant Address := Compute_Address;
Q : String (X .. Y) := "abc";
   .
   .
   .
for QAddress use Q_Address;

This is accepted by GNAT (and other Ada 95 compilers) and is also backwards compatible with Ada 83. A fuller description of the restrictions on address specifications is found in the GNAT Reference Manual.

E.1.6 Address Representation Clauses

The DEC Ada compiler supports address representation clauses for objects and imported subprograms but does not support address representation clauses for packages or tasks. On OpenVMS VAX systems, address representation clauses for task entries are not supported.

GNAT allows limited addresses for task entries in address representation clauses in the range of 0--63.

E.1.7 Other Representation Clauses

Representation clauses are based on the target machine's word, byte, and bit order numbering.

On DEC Ada for OpenVMS VAX, the record representation clause maximum alignment is 2⁹. On DEC Ada for OpenVMS Alpha and on GNAT, the maximum is 2¹⁶.

GNAT supports in a compatible manner all the representation clauses supported by DEC Ada. In addition, it supports representation clause forms that are new in Ada 95, including COMPONENT_SIZE and SIZE clauses for objects.

E.2 Package STANDARD

The package STANDARD, as implemented by DEC Ada, is fully described in the Reference Manual for the Ada Programming Language (ANSI/MIL-STD-1815A-1983) and in the DEC Ada Language Reference Manual. As implemented by GNAT, the package STANDARD is described in the Ada 95 Reference Manual.

For a discussion of the predefined types in this appendix, see Section E.1.

In addition, DEC Ada supports the Latin-1 character set in the type CHARACTER. GNAT supports the Latin-1 charater set in the type CHARACTER and also Unicode (ISO 10646 BMP) in the type WIDE_CHARACTER.

The floating-point types supported by GNAT are slightly different from those supported by DEC Ada. For more information, see Section E.1.2.

E.3 Package SYSTEM

Both the Ada 95 and Ada 83 Reference Manuals permit a compiler to add implementation-dependent declarations to package SYSTEM. In normal mode, GNAT does not add any, so the version of SYSTEM provided by GNAT exactly matches that in the Ada 95 Reference Manual. Thus it includes the Ada 95 declarations for BIT_ORDER and DEFAULT_BIT_ORDER, which are not in DEC Ada.

DEC Ada, unlike GNAT, adds an extensive set of implementation-dependent declarations to package SYSTEM, and package SYSTEM differs for each DEC Ada platform. A complete specification of SYSTEM is in Appendix F of the DEC Ada Language Reference Manual.

To minimize changes required for programs that make use of DEC Ada (on OpenVMS Alpha) extensions, GNAT provides the pragma EXTEND_SYSTEM, invoked by:

This pragma extends the set of definitions in SYSTEM to include those in package SYSTEM.AUX_DEC, encompassing the full set of DEC Ada extensions. These definitions are incorporated directly into package SYSTEM, as though they had been declared there in the first place. For a list of the declarations added, see the specification of this package, which can be found in the file S-AUXDEC.ADS in the GNAT library. The pragma also provides the following conversion functions, which are also in package SYSTEM on DEC Ada:

• IMPORT_ADDRESS
• IMPORT_LARGEST_VALUE
• IMPORT_VALUE
• TO_ADDRESS(INTEGER)
• TO_ADDRESS(UNSIGNED_LONGWORD)
• TO_ADDRESS(universal_integer)
• TO_INTEGER(ADDRESS)
• TO_UNSIGNED_LONGWORD(ADDRESS)

The pragma EXTEND_SYSTEM is a configuration pragma, which means that it can be placed in the file GNAT.ADC, so that it will automatically apply to all subsequent compilations.

An alternative to the nonstandard EXTEND_SYSTEM pragma is a context clause added to the unit that references these facilities, as follows:

with SYSTEM.AUX_DEC; use SYSTEM.AUX_DEC;

The effect is not quite semantically identical to incorporating the declarations directly into package SYSTEM, but most programs will not notice a difference unless they use prefix notation (for example, SYSTEM.INTEGER_8) to reference the entities directly in package SYSTEM. For units containing such references, the prefixes must either be removed, or the pragma EXTEND_SYSTEM must be used.

DEC Ada does not allow the recompilation of the package SYSTEM. Instead DEC Ada provides several pragmas (SYSTEM_NAME, STORAGE_UNIT, and MEMORY_SIZE) to modify values in the package SYSTEM.

GNAT permits the recompilation of package SYSTEM by means of the special qualifier /STYLE=GNAT. This qualifier can be used if it is necessary to change constants in SYSTEM. GNAT does not permit the specification of SYSTEM_NAME, STORAGE_UNIT, or MEMORY_SIZE by any other means.

The package SYSTEM on GNAT declares SYSTEM_NAME as follows:

type Name is (SYSTEM_NAME_GNAT);
   System_Name : constant Name := SYSTEM_NAME_GNAT;

On GNAT systems, the pragma SYSTEM_NAME takes the enumeration literal SYSTEM_NAME_GNAT. On VAX, it takes VAX_VMS. In DEC Ada for OpenVMS Alpha, it takes OpenVMS_AXP.

E.4 Tasking and Task-Related Features

The concepts relevant to a comparison of tasking on GNAT and on DEC Ada for OpenVMS systems are discussed in the following sections.

For detailed information on concepts related to tasking in DEC Ada, see the DEC Ada Language Reference Manual and the relevant run-time reference manual.

E.4.1 Implementation of Tasks in DEC Ada and GNAT

DEC Ada tasks and GNAT tasks cannot be combined in the same program.

Implementation is as follows in DEC Ada and GNAT:

• On OpenVMS Alpha systems, each DEC Ada task (except a passive task) is implemented as a single stream of execution that is created and managed by the kernel. On these systems, DEC Ada tasking support is based on DECthreads, an implementation of the POSIX standard for threads.
  On OpenVMS Alpha systems, DEC Ada tasks and foreign code that calls DECthreads routines can be used together. The interaction between Ada tasks and DECthreads routines can have some benefits. For example, on OpenVMS Alpha systems, DEC Ada can call C code that is already threaded.
• On OpenVMS VAX systems, the Ada Run-Time Library has its own threading system, and threading systems cannot be mixed. Therefore, although DECthreads is available on OpenVMS VAX systems, DECthreads routines cannot be called from DEC Ada programs on VAX systems.
• GNAT on OpenVMS Alpha implements tasking using the same underlying DECthreads mechanism as DEC Ada on OpenVMS Alpha.

On OpenVMS Alpha systems, task IDs are assigned at activation. On VAX systems, task IDs are assigned at task creation. On GNAT systems, task IDs are also assigned at task creation but do not have the same form or values as task ID values in DEC Ada. There is no null task, and the environment task does not have a specific task ID value.

The DEC Ada Run-Time Library always assigns %TASK 1 to the environment task that executes the main program. On OpenVMS Alpha systems, %TASK 0 is often used for tasks that have been created but are not yet activated. On OpenVMS VAX systems, the run-time library always assigns %TASK 0 to the null task that executes when there are no other tasks (including the main program) eligible to execute. The null task is a special task created by the run-time library, and you cannot apply most debugger commands to it.

E.4.3 Task-Related Pragmas

DEC Ada supplies the following task-related pragmas:

• MAIN_STORAGE (VAX only)
  On OpenVMS VAX systems, the pragma MAIN_STORAGE allows a fixed-size stack and stack storage areas to be specified for the environment (or main) task. It also causes the stack to be allocated in the P0 region rather than in the P1 region.
• TASK_STORAGE
  DEC Ada supplies the pragma TASK_STORAGE, which allows the specification of the size of the guard area for a task stack. (The guard area forms an area of memory that has no read or write access and thus helps in the detection of stack overflow.) If the pragma TASK_STORAGE specifies a value of zero, on OpenVMS VAX systems no guard area is created; on OpenVMS Alpha systems a minimal guard area is created.
  In the absence of a pragma TASK_STORAGE, a default guard area is created.

GNAT supplies the following task-related pragmas:

• TASK_INFO
  This pragma appears within a task definition and applies to the task in which it appears. The argument must be of type SYSTEM.TASK_INFO.TASK_INFO_TYPE.
• TASK_STORAGE
  GNAT implements pragma TASK_STORAGE in the same way as DEC Ada.

GNAT does not implement the pragma MAIN_STORAGE because it applies to VAX systems only.

Both DEC Ada and GNAT supply the pragmas PASSIVE, SUPPRESS, and VOLATILE, although GNAT ignores the pragma PASSIVE. In Ada 95, the effect of passive tasks can be achieved by use of protected types.

E.4.4 Scheduling and Task Priority

DEC Ada implements the Ada language requirement that when two tasks are eligible for execution and they have different priorities, the lower priority task does not execute while the higher priority task is waiting. The DEC Ada Run-Time Library keeps a task running until either the task is suspended or a higher priority task becomes ready.

On OpenVMS VAX systems, the operating systems issues the process and the Ada RTL divides up tasks within the process. The default strategy is first-in first-out (FIFO) with preemption. Tasks of equal priority are processed in FIFO order. A task is run until it suspends. When it later resumes, it is placed at the rear of the ready queue for its priority level.

On OpenVMS Alpha systems, the default strategy is round-robin with preemption. Tasks of equal priority take turns at the processor. A task is run for a certain period of time and then placed at the rear of the ready queue for its priority level.

DEC Ada provides the implementation-defined pragma TIME_SLICE, which can be used to enable or disable round-robin scheduling of tasks with the same priority. On VAX systems, the procedure SYSTEM_RUNTIME_TUNING.SET_TIME_SLICE is also available.

DEC Ada task priorities can be changed dynamically at run time to values of the subtype PRIORITY, as well as to the values of OpenVMS VAX real-time and system priorities.

On VAX systems, the duration of a time slice can also be specified. When a positive, nonzero time slice is specified with either the pragma TIME_SLICE or the procedure SYSTEM_RUNTIME_TUNING.SET_TIME_SLICE, the default FIFO scheduling is changed to round-robin scheduling. Tasks of the same priority take turns at the processor for the specified amount of time (in seconds).

On VAX systems, the debugger SET TASK/TIME_SLICE=t command allows the disabling of time slicing (SET TASK/TIME_SLICE=0.0) or the specification of a new value for a pragma TIME_SLICE. Therefore, this command can be used to time the execution of tasking programs or to diagnose problems that may be masked by the use of time slicing.

On VAX systems, there is an interaction between DEC Ada time slicing and the debugger watchpoint implementation. When watchpoints are set, the debugger can automatically increase the value of the pragma TIME_SLICE to 10.0. Slowing down the time-slice rate prevents these problems from occurring.

See the relevant DEC Ada run-time reference manual for information on using the pragmas to control DEC Ada task scheduling.

GNAT follows the scheduling rules of Annex D (real-time Annex) of the Ada 95 Reference Manual. In general, this scheduling strategy is fully compatible with DEC Ada although it provides some additional constraints (as fully documented in Annex D). GNAT implements time slicing control in a manner compatible with DEC Ada, by means of the pragma TIME_SLICE, whose semantics are identical to the DEC Ada pragma of the same name. Note that it is not possible to mix GNAT tasking and DEC Ada tasking in the same program, because the two run-times are not compatible.