HP OpenVMS Systems
Content starts here

DEC Ada
Technical Overview and Comparison on DIGITAL Platforms
Previous Contents Index

C.6 Package SYSTEM

The following list compares the differences between implementations of the package SYSTEM on VADS and on DEC Ada:

  • Both implementations have the types NAME and ADDRESS, as specified by the Ada language standard.
    On VADS, the type NAME has only one value. On DEC Ada, the type NAME is enumerated.
  • Both VADS and DEC Ada have the constant NO_ADDR.
    On VADS, this constant has the same value as ADDRESS_ZERO. On DEC Ada, the constants ADDRESS_ZERO and NULL_ADDRESS are also available.
  • The range for subtype PRIORITY differs between VADS and DEC Ada. VADS specifies a range of 0 .. 99. DEC Ada specifies the subtype PRIORITY to be of the type INTEGER with a range of 0 .. 15.
  • Named number values differ between VADS and DEC Ada.
  • On VADS, the subprogram MEMORY_ADDRESS is provided. On DEC Ada, the conversion function TO_ADDRESS in the package ADDRESS_OPERATIONS is provided and recommended.
  • DEC Ada has address, bit, and unsigned manipulations; VADS has bit and unsigned in separate packages.
  • VADS provides the types PROGRAM_ID and TASK_ID.

On DEC Ada, the package SYSTEM has the following functions:

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

The VADS and DEC Ada compilers provide additional constant declarations in the predefined package SYSTEM as shown in Table C-6.

Table C-6 Constants in Package SYSTEM
Number Value Product
MIN_INT --2.0 63
--2.0 63 		VADS
DEC Ada
MAX_INT 2 63 --1
2 63 --1 		VADS
DEC Ada
MAX_DIGITS 15 VADS and DEC Ada
MAX_MANTISSA 63
31 		VADS
DEC Ada
FINE_DELTA 2.0 -63
2.0 -31 		VADS
DEC Ada
MEMORY_SIZE 2.0 63--1 DEC Ada

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

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

In VADS, the pragmas SYSTEM_NAME, STORAGE_UNIT, and MEMORY_SIZE are recognized by the implementation but have no effect. The implementation does not allow SYSTEM to be modified by means of pragmas. However, the same effect can be achieved by recompiling the SYSTEM package with altered values. Such a compilation causes other units in the standard library to become out of date. Consequently, such recompilations should be made in a library other than STANDARD.

C.7 Tasking and Task-Related Features

The concepts particularly relevant to a comparison of tasking on VADS and on DEC Ada for DIGITAL UNIX 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.

C.7.1 Implementation of Tasks in DEC Ada for DIGITAL UNIX Systems

DEC Ada tasks on DIGITAL UNIX systems run in the context of threads that are created and managed by the DIGITAL UNIX kernel. DEC Ada tasking support is based on DECthreads, an implementation of the proposed POSIX standard for threads. For more information, see the DEC Ada Run--Time Reference Manual for DEC OSF/1 Systems.

C.7.2 Task-Related Pragmas

VADS supplies the following task-related pragmas:

  • IMPLICIT_CODE
  • INITIALIZE
  • NOT_ELABORATED

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.) On DIGITAL UNIX systems, if the pragma TASK_STORAGE specifies a value of zero, a minimal guard area is created.

In the absence of a pragma TASK_STORAGE, a default guard area is created.

Both VADS and DEC Ada supply the pragmas PASSIVE, SUPPRESS, and VOLATILE.

For more information on these pragmas, see Table C-7.

C.7.3 Scheduling and Task Priority

On DIGITAL UNIX systems, the default strategy is that tasks of equal priority take turns at the processor (round-robin task scheduling). A task is run for a certain period of time, then placed at the rear of the ready queue for that priority.

DEC Ada provides implementation-defined pragma TIME_SLICE, which can be used to enable or disable round-robin scheduling of tasks with the same priority.

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

See the relevant DEC Ada run-time reference manual for information on using the pragma PRIORITY to control DEC Ada task scheduling. See the DEC Ada Run--Time Reference Manual for DEC OSF/1 Systems or the specification of the DEC Ada package SET_TASK_PRIORITY for more information on dynamically changing task priorities on DIGITAL UNIX systems.

C.7.4 External Interrupts

VADS allows task entries to be associated with DIGITAL UNIX signals. DIGITAL UNIX handles all interrupts and faults initially and returns control to the user program as a signal.

The VADS Runtime System (RTS) sets up the following signal handlers:

  • SIGALRM
  • SIGBUS
  • SIGFPE
  • SIGILL
  • SIGSEGV
  • SIGTRAP

On DEC Ada, external interrupts can be associated with task entries.

C.8 Pragmas and Pragma-Related Features

Both DEC Ada and VADS supply all language-defined pragmas as specified by the Ada standard. These pragmas are as follows:

  • CONTROLLED
  • ELABORATE
  • INLINE
  • INTERFACE
  • LIST
  • MEMORY_SIZE
  • OPTIMIZE
  • PACK
  • PAGE
  • PRIORITY
  • SHARED
  • STORAGE_UNIT
  • SUPPRESS
  • SYSTEM_NAME

VADS and DEC Ada restrict the predefined language pragmas INLINE and INTERFACE. For more information, see Section C.8.1.

Table C-7 summarizes the differences between pragmas supplied by VADS and pragmas supplied by DEC Ada. These differences can affect applications being ported between VADS and DEC Ada.

Table C-7 is not intended to provide a complete discussion of DEC Ada and VADS pragmas. In particular, DEC Ada pragmas not available on the DIGITAL UNIX platform are not mentioned.

Table C-7 Summary of VADS and DEC Ada Pragmas
Pragma Product Comments
BIT_PACK VADS Indicates to the compiler that packing down to the bit level is desired. Pragmas BIT_PACK, PACK, and BYTE_PACK take the same arguments and can be used in the same source contexts.
BUILT_IN VADS Used in some parts of the code for TEXT_IO, MACHINE_CODE,
UNCHECKED_CONVERSION,
UNCHECKED_DEALLOCATION and lower level support packages in STANDARD. It is reserved and cannot be directly accessed.
BYTE_PACK VADS Indicates to the compiler that packing down to the byte level is desired. Components at least as large as, or larger than, a byte are packed at byte boundaries. Pragmas BIT_PACK, PACK, and BYTE_PACK take the same arguments and can be used in the same source contexts.
COMMON_OBJECT DEC Ada Enables the shared use of objects that are stored in overlaid storage areas.
COMPONENT_ALIGNMENT DEC Ada Specifies the kind of alignment used for the components of the array or record types to which it applies.
CONTROLLED Both Takes an access type as a parameter and specifies that the access type is not subject to automatic storage reclamation except under certain conditions (for example, when leaving the innermost block statement, subprogram body, or task body that encloses the access type declaration, or after leaving the main program.)

This pragma is essentially always in effect for DIGITAL implementations. It is recognized by Rational implementations but has no effect in the current release.

EXPORT_FUNCTION Both In DEC Ada, allows DEC Ada subprograms to be called by other DEC languages.
EXPORT_OBJECT Both In DEC Ada, takes the size option as one of its optional arguments.
EXPORT_PROCEDURE Both In VADS, creates a global symbol for an Ada subprogram (function or procedure) or object so that it can be referenced by non-Ada code. In DEC Ada, allows DEC Ada subprograms to be called by other DIGITAL languages.
EXPORT_VALUED_PROCEDURE DEC Ada Allows an Ada procedure to behave as a function that both returns a value and causes side effects on its parameters when it is called from a routine written in another programming language.
EXTERNAL VADS Supports calling Ada subprograms from foreign languages. The compiler generates code for the subprogram that is compatible with the calling conventions of the foreign language. The subprogram can also be called from Ada normally. The supported languages and restrictions on parameter and result types are the same as for the pragma INTERFACE.

This pragma has an effect only when the calling conventions of the foreign language differ from those of Ada.

This pragma is analogous to the DEC Ada EXPORT pragmas (EXPORT_OBJECT, EXPORT_FUNCTION, and EXPORT_PROCEDURE) for objects and subprograms.

EXTERNAL_NAME VADS Allows the user to specify a link for an Ada variable or subprogram so that the object can be referenced from other languages. DIGITAL implementations achieve the same effect with export pragmas.
FLOAT_REPRESENTATION DEC Ada Specifies the choice of representation to be used for the predefined floating-point types in the package STANDARD. Use of this pragma is interpreted as an implicit recompilation of the predefined STANDARD environment.
GENERIC_POLICY VADS Instructs the compiler how to generate code for a generic package or subprogram and its instantiations.
IMPLICIT_CODE VADS Specifies that implicit code generated by the compiler is allowed (ON) or disallowed (OFF). This pragma is used only within the declarative part of a machine code procedure.
IMPORT_FUNCTION Both In DEC Ada, takes an internal name denoting a function and optionally takes an external designator (the name of a linker global symbol), parameter types, result type, parameter mechanisms, and result mechanism as arguments.
IMPORT_OBJECT Both In DEC Ada, takes an internal name denoting an object and optionally takes an external designator (the name of a linker global symbol) and size (a linker absolute global symbol that will be defined in the object module) as arguments.
IMPORT_PROCEDURE Both In VADS and DEC Ada, associates an Ada name with the global symbol for a non-Ada subprogram (function or procedure) or object so that an Ada subprogram can call the subprogram or reference the object.
IMPORT_VALUED_PROCEDURE DEC Ada In DEC Ada, takes an internal name denoting a procedure and optionally takes an external designator (the name of a linker global symbol), parameter types, and parameter mechanisms as arguments. The pragma INTERFACE must be used with this pragma.
INITIALIZE VADS When placed in a library-level package, spec, or body, this pragma causes all objects in the package to be initialized as indicated (statically or dynamically).
INLINE Both Specifies that the subprogram bodies should be expanded inline at each call whenever possible. In the case of a generic subprogram, the program applies to calls of its instantiations.

VADS implementations add that recursive calls can be expanded with the pragma up to the maximum depth of 4.

Restrictions for both VADS and DEC Ada implementations. DEC Ada implementations sometimes decide to inline implicitly.

INLINE_GENERIC DEC Ada Specifies that inline expansion of the generic body is desired for each instantiation of the named generic declarations or of the particular named instances (does not apply to calls of instances of generic subprograms).
INLINE_ONLY VADS When used in the same way as pragma INLINE, indicates to the compiler that the subprogram must always be inlined. This is very important for some code procedures.

This pragma also suppresses the generation of a callable version of the routine that saves code space.

The DEC Ada compiler uses internal heuristics to optimize code.

INSTANCE_POLICY VADS Specifies whether replicated or shared code is to be generated for specific instantiations of a generic.
INTERFACE Both In VADS, supports calls to ADA, C, PASCAL, FORTRAN, and UNCHECKED language functions. The Ada specifications can be either functions or procedures. The pragma INTERFACE is also used to call code written in unspecified languages using UNCHECKED for the language name.

DEC Ada recognizes ADA, C, FORTRAN, and BLISS. Both compilers implement the pragma INTERFACE_NAME. DEC Ada also provides several import pragmas.

See Restrictions on the Pragma INTERFACE for information on restrictions for this pragma.

INTERFACE_NAME Both In VADS, allows variables or subprograms defined in another language to be referenced directly in Ada. VADS also provides the package LANGUAGE, which defines the prefixes and suffixes in the link names generated by the system linker.

Analogous to the pragmas IMPORT_FUNCTION and IMPORT_PROCEDURE but INTERFACE_NAME has fewer parameters. Also analogous to IMPORT_OBJECT. Differences between implementations in string parameter interpretation. DEC Ada does not evaluate the second parameter.

LINK_WITH VADS Used to pass arguments to the linker.

To pass options to the linker, DEC Ada supports the -l ldflags option, the LDFLAGS environment variable, and the aimport command.

LIST Both Takes one of the identifiers ON or OFF as the single argument. This pragma specifies that listing of the compilation is to be continued or suspended until a LIST pragma with the opposite argument is given within the same compilation.
LOCAL_ACCESS VADS This pragma is meaningful only in Distributed Ada (DADAS) products. It has no effect when using a standard VADS compiler.
MEMORY_SIZE Both The effect of this pragma is to use the value of the specified numeric literal for the definition of the named number MEMORY_SIZE. In VADS, this pragma is recognized by the implementation but has no effect in the current release.
NO_IMAGE VADS Suppresses the generation of the image array used for the IMAGE attribute of enumeration types. This eliminates the overhead required to store the array in the executable image.
NON_REENTRANT VADS Indicates to the compiler that the subprogram will not be called recursively allowing the compiler to perform specific optimizations.
NOT_ELABORATED VADS Suppresses the generation of elaboration code and issues warnings if elaboration code is required.
OPTIMIZE Both This pragma specifies whether time or space is the primary optimization criteria.

In VADS, this pragma is recognized but has no effect in the current release.

OPTIMIZE_CODE VADS Specifies whether the code should be optimized by the compiler or not.
PACK Both In VADS and DEC Ada, this pragma instructs the compiler to minimize gaps between components in the representation of composite types.

Both implementations have restrictions on what is considered packable.

PAGE Both Implemented as described in Annex B of the Ada language standard.

In VADS, it is also recognized by the source code formatting tool a.pr .

PASSIVE Both In VADS, the pragma directs the compiler to optimize certain tasking operations. It has five forms.

In DEC Ada, the pragma takes an argument indicating whether or not to make a containing task passive. The default (no arguments) indicates a desire to make the containing task passive. This pragma must be specified within a task specification and can be for a task type or a single task.

PRIORITY Both Specifies the priority of a task or main program. In VADS, the allowable range is 0 .. 9. In DEC Ada, the allowable range is 0 .. 15.
REMOTE_ACCESS VADS Is meaningful only in Distributed Ada (DADS) products. It has no effect when using a standard VADS compiler.
RTS_INTERFACE VADS Allows for the replacement of the default calls made implicitly at run time to the underlying RTS routines.
SHARE_CODE
SHARE_BODY 		VADS Provides for the sharing of object code between multiple instantiations of the same generic subprogram or package body.

The pragmas SHARE_CODE and SHARE_BODY are analogous to the DEC Ada pragma SHARE_GENERIC, which is available on OpenVMS VAX systems only. The VADS version of these pragmas allow generic code sharing to be turned off.

SHARED Both This pragma specifies that every read or update of the variable is a synchronization point for that variable.

In VADS, the pragma identifies a scalar or access variable that might be read or written by different tasks. The Ada optimizer does not attempt to optimize away or move any reads or writes to this variable.

In DEC Ada, there are restrictions on floating-point types.

STORAGE_UNIT Both The effect of this pragma is to use the value of the specified numeric literal for the definition of the named number STORAGE_UNIT.

On VADS, this pragma is recognized but has no effect. The implementation does not allow the package SYSTEM to be modified by means of pragmas. However, the same effect can be achieved by recompiling the package SYSTEM with altered values.

On DEC Ada, this pragma allows only 8 (bits).

SUPPRESS Both VADS does not suppress DIVISION_CHECK and sometimes does not suppress OVERFLOW_CHECK. VADS also provides ALL_CHECKS (similar to the DEC Ada pragma SUPPRESS_ALL) and EXCEPTION_TABLES (optimization that disables exception handling).
SUPPRESS_ALL Both Suppresses all permitted run-time checks. It has no arguments.
SUPPRESS_ELABORATION_CHECKS VADS In VADS, this pragma suppresses all elaboration checks in a given compilation unit. It has no arguments.

In DEC Ada, this pragma specifies that all run-time checks are suppressed.

SYSTEM_NAME Both This pragma specifies the name of an allowable configuration. The pragma is recognized by VADS but has no effect in the current release.
TASK_ATTRIBUTES VADS Specifies the task attributes of the task or tasks of the task type. The pragma has two forms. The second form is applicable to any task object.
TASK_STORAGE DEC Ada Allows the specification of additional storage for each task activation.
TITLE DEC Ada Supersedes the default title portion or subtitle portion or both in a compilation listing.
VOLATILE Both Instructs the compiler to obtain the value of a variable from memory each time it is used.

In VADS, guarantees that loads and stores to the named object are performed as expected after optimization. The object declaration and the pragma must both occur (in this order) immediately within the same declarative part or package specification.

WARNINGS VADS Selectively suppresses warnings on a single statement or group of statements.
1The package MACHINE_CODE contains a description for the MC88100 processor.

The Ada language specifies that unrecognized pragmas are accepted but ignored. Therefore, programs using a VADS-only pragma on a DIGITAL implementation compile but do not necessarily run as expected.

C.8.1 Pragma-Related Restrictions

Restrictions on the Pragma INLINE

VADS applies the following restrictions to the pragma INLINE:

  • Recursive calls are expanded to maximum depth of 4.
  • Subprograms cannot declare the following:
    • Tasks
    • Packages
    • Exceptions
    • Types
    • Nested subprograms

DEC Ada applies the following restrictions to the pragma INLINE:

  • Parameters cannot be a task type.
  • Function results cannot be task types, unconstrained array types, or unconstrained types with discriminants.
  • Bodies cannot declare the following:
    • Subprogram body or stub (imported subprogram is allowed)
    • Tasks
    • Generic declarations
    • Instantiations
    • Exceptions
    • Access types (types derived from access types allowed)
    • Array or record types
    • Dependent tasks
    • Direct recursive calls of subprogram or containing subprogram, directly or via a renaming

Restrictions on the Pragma INTERFACE

Table C-8 describes the restrictions on the pragma INTERFACE on VADS and DEC Ada.

Table C-8 Restrictions on the Pragma INTERFACE
Restriction VADS DEC Ada
Languages accepted: Ada, C, Pascal, Fortran, unchecked. Ada, Bliss, C, Fortran. Default is C on DIGITAL UNIX.
Parameter passing: Language specifies default mechanism. Language specifies default mechanisms but can be overridden with an EXPORT pragma.
  Ada: use Ada rules. Ada: use internal Ada rules.
  C: parameters must be mode 'in'; scalar, access or SYSTEM.ADDRESS types for parameters and results. Bliss, C: parameters must be mode 'in'; cannot be record or task type. Result cannot be a string, an array, or a record.
  Fortran: pass by reference and must be of type ADDRESS. Result must be a scalar. Fortran: parameters cannot be a task. Result cannot be a string, an array, or a record.
  Unchecked: similar to the language Ada. Not available on DEC Ada for DIGITAL UNIX.

On DEC Ada, pragmas can pass and return by value 64-bit parameters.

C.9 Library of Predefined Units

A library of predefined units is provided as part of the VADS and DEC Ada implementations. The following predefined units are provided by both implementations:

  • Package CALENDAR
  • Package DIRECT_IO
  • Package IO_EXCEPTIONS
  • Package SEQUENTIAL_IO
  • Package STANDARD
  • Package SYSTEM
  • Package TEXT_IO
  • Generic function UNCHECKED_CONVERSION
  • Generic procedure UNCHECKED_DEALLOCATION

In VADS, UNCHECKED_CONVERSION cannot be instantiated with a target type that is an unconstrained array type or an unconstrained record type with discriminants.

There are no restrictions on the types with which UNCHECKED_DEALLOCATION can be instantiated. No checks are performed on released objects.

In addition, VADS provides the package LOW_LEVEL_IO and the package MACHINE_CODE. Package MACHINE_CODE provides an assembly language interface for the target machine, including the necessary record types needed in the code statement, an enumeration type containing all the opcode mnemonics, a set of register definitions, and a set of addressing mode functions.

DEC Ada does not provide the package MACHINE_CODE. Instead, DEC Ada recommends importing assembler code. (On an Alpha system, this is not costly in terms of CPU.)

Previous Next Contents Index