HP OpenVMS Systems

DEC Ada
Technical Overview and Comparison on DIGITAL Platforms

Appendix D
A Comparison of Rational's Apex and DEC Ada for DIGITAL UNIX Systems

This appendix compares Rational's Ada 83 compiler, Apex for DEC Alpha AXP OSF/1 (DIGITAL UNIX) and DEC Ada on DIGITAL UNIX systems. It also includes differences in the implementation or interpretation of the Ada standard.

Apex also provides an Ada 95 compiler validated to the ACVC 2.1 suite.

Note

In this appendix, Apex refers to the Apex product line from Rational Software Corporation.

Apex is an integrated development environment for Ada and mixed-language applications. Apex includes a mature, production-quality, optimizing Ada compiler.

As a development environment, Apex provides integrated configuration management, source code browsing and automated build control. Rational Software also provides a range of layered products to work with Apex, such as Rational Rose for Visual Modeling, TestMate for test management, and Ada Analyzer for static analysis of source code.

The development environment for DEC Ada is provided by the DECset tools.

Rational Software can be reached on the World Wide Web at http://www.rational.com.

This appendix discusses the following topics:

Language-related features
Representation clauses
Dope vectors
Package STANDARD
Package SYSTEM
Tasking and task-related features
Pragmas and pragma-related features
Library of predefined units
Bindings
Implementation-defined attributes
Compiler and run-time interfacing
User interface
Input-output
Implementation limits

D.1 Language-Related Features

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

D.1.1 Integer Types

Both Apex and DEC Ada provide the following integer types:

SHORT_SHORT_INTEGER
SHORT_INTEGER
INTEGER
LONG_INTEGER

Table D-1 lists the predefined integer types provided by Apex and DEC Ada, with first and last values.

**Table D-1 Range of Values for Predefined Integer Types**
Type	T'FIRST	T'LAST	T'SIZE
SHORT_SHORT_INTEGER	--2 ⁷	2 ⁷--1	8
SHORT_INTEGER	--2 ¹⁵	2 ¹⁵--1	16
INTEGER	--2 ³¹	2 ³¹--1	32
LONG_INTEGER	--2 ⁶³	2 ⁶³--1	64

DEC Ada has defined the following additional integer types:

INTEGER_8
INTEGER_16
INTEGER_32
INTEGER_64
LARGEST_INTEGER

Apex has defined the INTEGER_[8,16,32,64] types in the package Interfaces. The following types are also defined there: UNSIGNED_[8,16,32,64]

D.1.2 Floating-Point Numbers and Representations

Apex provides the following floating-point types:

SHORT_FLOAT
FLOAT
LONG_FLOAT

In the package Interfaces Apex defines the following additional floating point types:

IEEE_FLOAT_32
IEEE_FLOAT_64

The predefined attributes and their values that yield the characteristics of each floating-point type are described in the compiler reference guide for Apex. This manual is delivered online in HTML format with the Apex product.

DEC Ada on DIGITAL UNIX implements the following floating-point numbers:

IEEE_SINGLE_FLOAT
IEEE_DOUBLE_FLOAT

Table D-2 lists the floating-point types declared in the package STANDARD and their default representations.

**Table D-2 Floating-Point Types and Default Representations**
Implementation	Predefined Type	Default Representation	Size (bits)	Digits (Precision)
	SHORT_FLOAT	IEEE 32 bit	32	6
Apex	FLOAT	IEEE 32 bit	32	6
	LONG_FLOAT	IEEE 64 bit	64	15

	FLOAT	IEEE single float	32	6
DEC Ada	LONG_FLOAT	IEEE double float	64	15
	LONG_LONG_FLOAT	IEEE double float	64	15

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 the DEC Ada Language Reference Manual. The DEC Ada run-time reference manuals also give information on the internal representation of the DEC Ada floating-point types.

On DIGITAL UNIX, 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 DIGITAL UNIX, the value of this pragma must be IEEE_FLOAT.

D.1.3 Record Representation Clause Maximum Alignment

On Apex implementations, the record representation clause maximum alignment is 16. On DEC Ada implementations, the maximum alignment is 2³ or 8.

D.1.4 Record and Array Component Alignment

For Apex, all noncomposite components are aligned on natural boundaries, unless overridden with record representation clauses.

On Apex, if representation clauses are used and the component does not start on a storage unit boundary, then it must be possible to store the component in a register with one move instruction.

On DEC Ada, all noncomposite components are aligned on natural boundaries (unless otherwise specified with the pragma COMPONENT_ALIGNMENT). 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 Alpha hardware runs more efficiently with naturally aligned data.

On DIGITAL UNIX systems, DEC Ada allows the simple expression in an alignment clause to have a value between 2⁰ and 2¹⁶ (inclusive).

In other words, the simple expression must be an integer in the range 1 .. 512, 1 .. 65536, or 1 .. 8 that is also a power of 2. The allocations then occur at addresses that are a multiple of the simple expression (a value of 2 aligns the data on a 2-byte boundary, a value of 4 aligns the data on a 4-byte boundary, and so on).

D.1.5 Type DURATION

The type DURATION has different ranges on Apex and DEC Ada. Table D-3 shows these ranges as well as other attributes of the type DURATION and their values on the two platforms.

**Table D-3 Properties of the Type DURATION**
Attribute	Value on Apex	Value on DEC Ada
DURATION'DELTA	1.00000000000000E--09	0.0001
DURATION'SMALL	1.00000000000000E--09	2.0 ^-14
DURATION'FIRST	--9799832789.158200441	--131072.0000
DURATION'LAST	9223372036.854778244	131071.9999
DURATION'LARGE	9.22337203685478E+09	131071.9999

D.1.6 Other Apex-Specific Type Information

The following list shows implementation-defined type information for Apex:

Maximum ARRAY and RECORD type size limits are 256_000_000 bits.
Unlimited precision arithmetic for computation with numeric literals.
Restricted number of literals within an enumeration type, to 2¹⁶.
The image of a character that is not a graphic character is defined as the corresponding 2- or 3- character identifier from package ASCII. The identifier is in uppercase without enclosing apostrophes.
Except for memory size, no specific limit on the length of the predefined type STRING. Any type derived from STRING is similarly unlimited.
Fixed-point types mapped to a 32-bit integer.

D.2 Representation Clauses

Representation clauses are based on the target machine's word, byte, and bit order numbering. Apex is consistent with machine architecture manuals for both "big-endian" and "little-endian" machines. Bits within a STORAGE_UNIT are numbered according to the target machine manuals. It is not necessary for a user to understand the default layout for records and other aggregates because fine control over the layout is obtained by the use of record representation clauses. It is possible to align fields correctly with structures and other aggregates from other languages by specifying the location of each element explicitly. The FIRST_BIT and LAST_BIT attributes can be used to construct bit manipulation code applicable to differently bit-numbered systems.

The only restriction on record representation clauses is that if a component does not start and end on a storage unit boundary, it must be possible to get it into a register with one move instruction.

The size of object modules is aligned. It is assumed that "mod 2" is a worst case restriction, assuming that even the C compiler aligns to a 2-byte boundary.

The alignment clause portion of a record representation must be a power of 2. The alignment is obeyed for all allocations of the record type with the following exceptions:

Object declared within a procedure
Objects created by an allocator

For these two exceptions, the maximum alignment obeyed is the default stack and heap alignment.

If a record is given a representation clause but no alignment clause, the compiler assumes that the record may be arbitrarily aligned (at an arbitrary bit offset within another structure, for example).

D.2.1 ADDRESS Attribute---Apex Implementations

The ADDRESS attribute is supported for the following entities:

Variables
Constants
Procedures
Functions

If the prefix of an address attribute is an object that is not aligned on a storage unit boundary, the attribute yields the address of the storage unit containing the first bit of the object. This is consistent with the definition of the FIRST_BIT attribute.

D.2.2 Restrictions on Unchecked Type Conversions

Both Apex and DEC Ada implementations provide both UNCHECKED_DEALLOCATION and UNCHECKED_CONVERSION.

Apex supports the generic function UNCHECKED_CONVERSION with the following restrictions on the class of types involved:

The actual subtype corresponding to the formal type TARGET must not be an unconstrained array type.
The actual subtype corresponding to the formal type TARGET must not be an unconstrained type with discriminants.

If the size of the source differs from the size of the target subtype, a warning is issued by the compiler and results may be unpredictable.

Any object allocated can be deallocated. Currently, Apex performs no checks on release objects. However, when an object is deallocated, its access variable is set to null. Subsequent deallocations using the null access variable are ignored.

DEC Ada supports the generic function UNCHECKED_CONVERSION with the following restrictions on the class of types involved:

The actual subtype corresponding to the formal type TARGET must not be an unconstrained array type.
The actual subtype corresponding to the formal type TARGET must not be an unconstrained type with discriminants.

When the target type is a type with discriminants, the value resulting from a call of the conversion function resulting from an instantiation of UNCHECKED_CONVERSION is checked to ensure that the discriminants satisfy the constraints of the actual subtype.

If the size of the source value is greater than the size of the target subtype, the high order of bits of the value is ignored (truncated). If the size of the source value is less than the size of the target subtype, the value is extended with zero bits to form the result value.

D.2.3 Additional Representation Clause Information---Apex Implementations

Apex supports the following:

Bit-level representation clauses
Enumeration representation clauses
Change of representation
Representation attributes of real types
Machine code insertions

D.2.4 Restrictions on Representation Clauses---DEC Ada Implementations

The representation clauses allowed in Apex are length, enumeration, record representation, and address clauses.

The representation clauses allowed in DEC Ada are length, enumeration, record representation, and address clauses.

In DEC Ada, a representation clause is not allowed for:

A generic formal type
A type that depends on a generic formal type
A composite type that has a component or subcomponent of a generic formal type
A type derived from a generic formal type

D.3 Dope Vectors

In Apex, an array dope vector is a sequence of triples (3 x 64-bit words, 192 bits) containing the size in bytes (size in bits if the array is packed) of the subarray for that dimension, the value of 'FIRST and the value of 'LAST.

An array subtype is completely static if its bounds are all static and its component subtype is static sized. The dope vector for a completely static array subtype is initialized statically. All other dope vectors are initialized by generated inline code.

Dope vectors are allocated in different ways as shown in the following table:

Static Allocation	If the array subtype is completely static or declared within a library level package spec or body, then the dope vector is allocated statically.
Stack Allocation	If the array subtype is dynamic and declared within a task, declare block, or subprogram body, the dope vector is allocated on the stack.
Heap Allocation	If the array subtype is declared in an allocator for an unconstrained array type, the dope vector is allocated in the words immediately preceding the allocated array object.
Record Allocation	If the array subtype is a dependent array subtype (for example, one of its bounds is a discriminant of an enclosing record), the dope vector is allocated in the static part of the record. The dope vector is initialized by record initialization code.

In DEC Ada, dope vectors are special descriptors that are used in some cases to pass record and array parameters between Ada subprograms or to return record and array function results. They are never used in calls to and from subprograms that are specified in an import, export, or INTERFACE pragma.

DEC Ada uses two kinds of dope vectors:

Dope vectors that describe a byte-aligned data element
Bit dope vectors that describe a bit-aligned data element

For more information on DEC Ada dope vectors, see the DEC Ada Run--Time Reference Manual for DEC OSF/1 Systems.

D.4 Parameter Passing

Small results are returned in registers. Large results with known targets are passed by reference. Large results of anonymous target and known size are passed by reference to a temporary created on the caller's stack. Large results of anonymous target and unknown size are returned by copying the value down from a temporary in the callee so the space used by the temporary can be reclaimed.

Apex passes up to six parameters in registers, the remaining parameters are passed on the stack. The MACHINE_CODE package requires the usage of parameters as operands be consistent with the type of operand expected by the MACHINE_CODE instruction, given that the parameters can be in registers or on the stack.

In DEC Ada when importing or exporting routines from other languages or when exporting Ada subprogram, you can explicitly specify the passing mechanisms for one or more parameters or function results.

Before deciding to explicitly specify the passing mechanisms, the compiler compilation notes can be used to determine which default mechanisms the compiler chooses for certain parameters or function results.

Once the parameter-passing mechanisms are explicitly specified, the MECHANISM option can be used in DEC Ada import or export pragmas to specify one of two values for each parameter. Similarly, the RESULT_MECHANISM option can be used to specify one of the same two values for each function result. The two mechanisms are as follows:

VALUE. Causes the value of the actual parameter or function result to be passed or returned.
REFERENCE. Causes an address of the value of the actual parameter to be passed; causes the address of the function result to be returned by the extra parameter method.

D.5 Package STANDARD

The package STANDARD is fully described in the Reference Manual for the Ada Programming Language (ANSI/MIL-STD-1815A-1983) and the the implementation of the package in DEC Ada is fully described in DEC Ada Language Reference Manual.

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

The differences between implementations of the package STANDARD on Apex and on DEC Ada are shown in the following list:

DEC Ada supports the Latin-1 character set in the type CHARACTER. Apex supports a 7-bit character set.
Apex supports the type SHORT_FLOAT, which is the same size as the DEC Ada type FLOAT.
By default, Apex has representation of a string with 1 byte per character. By default, DEC Ada has 1 byte per character.

Table D-4 compares the sizes of integer and floating-point types between the package STANDARD on Apex and on DEC Ada.

**Table D-4 Comparison of Type Sizes in the Package STANDARD**
Type	Apex Size	DEC Ada Size
SHORT_FLOAT	32 bits	N/A
FLOAT	32 bits	32 bits
LONG_FLOAT	64 bits	64 bits
LONG_LONG_FLOAT	N/A	64 bits
SHORT_SHORT_INTEGER	N/A	8 bits
SHORT_INTEGER	16 bits	16 bits
INTEGER	32 bits	32 bits
LONG_INTEGER	64 bits	64 bits

D.6 Package SYSTEM

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

Both implementations have the types NAME and ADDRESS, as specified by the Ada language standard.
On Apex, the type NAME has only one value. On DEC Ada, the type NAME is enumerated.
Both Apex and DEC Ada have the constant NO_ADDR.
On Apex, 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 Apex and DEC Ada. Apex 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 Apex and DEC Ada.
On Apex, 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; Apex has bit and unsigned in separate packages.
Apex 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 Apex and DEC Ada compilers provide additional constant declarations in the predefined package SYSTEM as shown in Table D-5.

**Table D-5 Constants in Package SYSTEM**
Number	Value	Product
MIN_INT	--2.0 ⁶³ --2.0 ⁶³	Apex DEC Ada
MAX_INT	2 ⁶³ --1 2 ⁶³ --1	Apex DEC Ada
MAX_DIGITS	15	Apex and DEC Ada
MAX_MANTISSA	63 31	Apex DEC Ada
FINE_DELTA	2.0 ^-63 2.0 ^-31	Apex DEC Ada
MEMORY_SIZE	2.0 ⁶³--1	DEC Ada

Neither Apex nor DEC Ada 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.

In Apex, the pragmas SYSTEM_NAME, STORAGE_UNIT, and MEMORY_SIZE are recognized by the implementation but have no effect.

D.7 Tasking and Task-Related Features

The concepts particularly relevant to a comparison of tasking on Apex 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.

D.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.

Apex is available in Threaded and Non-Threaded versions. The Threaded version uses DECthreads. Apex Ada tasks can either be managed within a single context or mapped to DECthreads, by selecting the appropriate predefined library.

D.7.2 Task-Related Pragmas

Apex supplies the following task-related pragmas:

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 Apex and DEC Ada supply the pragma SUPPRESS.

For more information on these pragmas, see Table D-6.

D.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.

Apex uses round-robin scheduling with tasks of equal priority.

D.7.4 External Interrupts

Apex 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 Apex 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.

D.8 Pragmas and Pragma-Related Features

Both DEC Ada and Apex 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

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

Table D-6 summarizes the differences between pragmas supplied by Apex and pragmas supplied by DEC Ada. These differences can affect applications being ported between Apex and DEC Ada.

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

**Table D-6 Summary of Apex and DEC Ada Pragmas**
Pragma	Product	Comments
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 Apex, 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	Apex	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. Allowed languages are ASM, C, ADA, FORTRAN, PASCAL, or UNCHECKED. Use C when calling from C++. 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	Apex	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. Allowed languages are ASM, C, ADA, FORTRAN, PASCAL, or UNCHECKED. Use C when calling from C++.
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	Apex	Instructs the compiler how to generate code for a generic package or subprogram and its instantiations.
IMPLICIT_CODE	Apex	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 Apex 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.
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. Apex implementations add that recursive calls can be expanded with the pragma up to the maximum depth of 4. Restrictions for both Apex 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	Apex	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	Apex	Specifies whether replicated or shared code is to be generated for specific instantiations of a generic.
INTERFACE	Both	In Apex, supports calls to ASM, ADA, C, PASCAL, FORTRAN, and UNCHECKED language functions. 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 Apex, allows variables or subprograms defined in another language to be referenced directly in Ada. Apex 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	Apex	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.
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 Apex, this pragma is recognized by the implementation but has no effect in the current release.
NOT_ELABORATED	Apex	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 Apex, this pragma is recognized but has no effect in the current release.
PACK	Both	In Apex 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.
PASSIVE	DEC ADA	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 Apex, the allowable range is 0 .. 99. In DEC Ada, the allowable range is 0 .. 15.
SHARED	Both	This pragma specifies that every read or update of the variable is a synchronization point for that variable. In Apex, 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 restric- tions 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 Apex, 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	Apex does not suppress DIVISION_ CHECK and sometimes does not suppress OVERFLOW_CHECK. Apex 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	Apex	In Apex, 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 Apex but has no effect in the current release.
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 Apex, 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.

¹The package MACHINE_CODE contains a description for the MC88100 processor.

Contents

Index