TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Ada 95 LRM Annex M: Implementation-Dependent Characteristics

The Ada language allows for certain machine dependences in a controlled manner. Each Ada implementation must document all implementation-defined characteristics.

This chapter provides information as required by the Ada 95 LRM Annex M. The imageplementation-dependent characteristics of Rational Apex are described in the following sections.


General

Scope


Lexical Elements

Character Set

Lexical Elements, Separators, and Delimiters

Pragmas

All Ada 95 pragmas as defined in the Ada 95 LRM, are followed to the letter. This includes the interfacing pragmas Convention, Export, Import, and Linker_Options as described in Annex B. Additional information on these pragmas can be found in Interfacing Pragmas.

Pragma Api

Designates a compilation unit as belonging to the user-visible portion of an API. The syntax is:

Arguments

Usage

Pragma Api must appear at the end of a compilation unit.

Pragma Assert

Raises an exception if a specified Boolean expression evaluates to False at run time. The syntax is:

Arguments

Usage

When pragma Assert is encountered at run time, the Boolean expression is evaluated. If the result is False, the exception System.Assertion_Error is raised; if the result is True, no action is taken.

This pragma can appear anywhere that a declaration or statement is allowed.

Pragma Calling_Convention

Pragma Calling_Convention is always used in conjunction with either a pragma Import or a pragma Export. The functionality described in this section applies to imported C/C++ routines and exported Ada routines.

Pragmas Import and Export tell the compiler that a certain subprogram is imported from or exported to another language. Pragma Calling_Convention gives additional instructions to the compiler about specific calling conventions to be used. This affects the code generated by the compiler for the subprogram call (if imported) or for the subprogram prologue and epilog (when exported). The syntax is:

Note that the first argument of a pragma Calling_Convention (the "Entity" argument) always names a subprogram which is also referenced by a pragma Import or Export. The other arguments of pragma Calling_Convention (which must be named) depend on whether the pragma applies to an imported or an exported subprogram.

Arguments/Attributes

Usage

Use pragma Calling_Convention to enable the running of different IEEE floating point models within the same program. Using pragma Calling_Convention, C/C++ code using a floating point model that includes NaNs (Not-a-Number) and Infs (Infinity), can be used with Apex Ada.

To enable this facility, you must add pragma Calling_Convention after the pragma Import line where you declare the C++ procedure in Ada.

This combination tells the compiler to load the floating point status register from the C_FLOATING_POINT_CONTROL field of the user configuration table before calling the C++ routine. After the C++ code returns, the value of the FLOATING_POINT_CONTROL field of the configuration table is restored to the floating point status register.

Additional information on this pragma can be found in pragma Calling_Convention.

Examples

The following contains examples of pragma Calling_Convention for both imported and exported subprograms.

Pragma Collection_Policy

Controls memory allocation for the collection designated by an access type. The syntax is:

Arguments

Usage

Pragma Collection_Policy must appear in the same declarative region as the access type to which it applies, after the access type's declaration and before any forcing occurrence of the access type. If the access type is a private type, the pragma must appear in the private part after the complete access-type declaration. If the pragma appears outside the specified areas, it is ignored.

Notes

Pragma Export_Elaboration_Procedure

Defines a global symbolic name for the elaboration procedure of a given compilation unit. The syntax is:

Arguments

Usage

Use this pragma to reference the elaboration procedure of an Ada module that is not otherwise elaborated. This exceptional case occurs when the module is not in the closure of the main program, or when the main program was not written in Ada.

Do not use this pragma unless you thoroughly understand the elaboration, runtime, and storage-model considerations.

Notes

Pragma Implicit_Code

Controls the generation of implicit code. The syntax is:

Usage

Pragma Implicit_Code controls the generation of implicit code. Implicit code is code generated for procedure entry and exit to support the calling conventions used by the compiler. Implicit code also includes any additional code generated due to the use of the X'Ref attribute (such as code to load a base register).

When pragma Implicit_Code(off) is specified, any stack allocation and the Storage_Check that is generated for the stack allocation are not generated.

Implicit code is always generated for a X'Ref attribute which requires it. A warning message is generated when Implicit_Code(off) is specified in such a case.

Pragma Initialize

This pragma is not legal in Ada 95. All variables are initialized, even if they have an address clause. If you do not want a variable to be initialized, use pragma Import:

Pragma License

Used in an API specification, allows compilation of code referencing the API to proceed only after acquiring a license to do so.

Arguments

Usage

Pragma License must appear at the end of a compilation unit that is a package declaration, a subprogram declaration, or a generic. Pragma Api must be applied to the same compilation unit and appear before pragma License.

Whenever the compiler encounters pragma License in the closure of a unit it is compiling, it attempts to acquire a license for the feature name and version given in the pragma. If it is unable to do so, the compilation will be aborted. At most one license for the name and version is required for any Apex session.

Example

Pragma Linker_Options

Passes arguments to the target linker. The syntax is:

Usage

This pragma can appear in any package specification or declarative part. Its argument is passed as a command line argument to the target linker whenever the unit containing the pragma is in the closure of the main program being linked.

In constructing the target linker command line argument, the Linker_Options argument is first divided into tokens. Tokens are delimited by white-space.

Tokens are then passed to the linker command line. Tokens beginning with "+" and "-" tokens are interpreted as linker switches. Tokens beginning with "/" tokens are interpreted as rooted filenames. If a token begins with "-", "+", or "/", it is left untouched.

If a token begins with neither "-" nor "+" nor "/", then it is assumed to name a file and is prefixed with pathname of the directory containing the Ada unit in which the pragma appears. (This behavior is different from VADS, in which unqualified names are interpreted in the context of the main program being linked).

If a main program's closure contains more than one pragma Linker_Options, their contents will be separated by blanks on the linker command line. The order in which the arguments appear is not defined.

If pragma Linker_Options appears in the implementation of an API, that is, in a unit that also contains pragma Api, its contents are passed to the linker when the API is used in the closure of a main program, not when the API itself is linked.

Pragma Main

Designates an Ada main unit and determines some aspects of its runtime behavior. The syntax is:

All expressions must be static; all integer expressions must be nonnegative.

Arguments

Usage

Use pragma Main after the end of the unit body of a parameterless library-unit subprogram to designate it as a main program. If the subprogram is a function, the type it returns must be Standard.Integer (the return value is passed to UNIX as the exit status of the program). In Ada 95, the subprogram must not be a child unit or a rename.

Pragma Main can have two effects. It:

Example

Use pragma Main as shown:

Pragma Optimize_Code

Specify whether the compiler should attempt to optimize through the machine code insertions. The syntax is:

Usage

Use pragma Optimize_Code in the declarative section of a machine code procedure to specify whether the compiler should attempt to optimize through the machine code insertions.

When pragma Optimize_Code(off) is specified, the compiler generates the code as specified.

Pragma Suppress_Elaboration_Checks

Suppresses all elaboration checks in a given compilation unit. The syntax is:

Arguments

None.

Usage

Use pragma Suppress_Elaboration_Checks at the end of any compilation unit to suppress elaboration checks for all subprograms in that unit. This is equivalent to placing a named pragma Suppress (Elaboration_Check) in each subprogram in the unit. For example;

is equivalent to


Declarations and Types

Scalar Types

Type Extensions


Names and Expressions

The following attributes are implemented in addition to those specified in the Ada 95 Reference Manual. Following the table is a more detailed description of each attribute.

Table 45 Implementation-Defined Attributes
Attribute
Meaning
'Compiler_Key
Identifies the compiler used to generate code for the specified object
'Compiler_Version
Yields the version of the compiler used to generate code for the specified object
'Dope_Address
Yields the address of the dope vector for an array object
'Dope_Size
Yields the size of the dope vector for an array object
'Entry_Number
Uniquely identifies an entry or generic
'Homogeneous
Specifies whether objects in a collection are of uniform size
'Ref
Generates a reference to the specified entity
'Type_Key
Uniquely identifies a type

Compiler_Key

For a prefix N that denotes the name of an entity, N'Compiler_Key yields the full pathname of the compiler key, which indicates the compiler that was used to generate code for the unit containing the definition of N.

The entity named by N can be a program unit (package, subprogram, task, or generic), an object (variable, constant, named number, or parameter), a type or subtype (but not an incomplete type), or an exception.

The value returned by this attribute is of type String; for example:

This attribute can be used for runtime detection of incompatibilities in data representation. It typically is used when passing messages over a network to ensure that the reader and writer agree on how to interpret the message.

Compiler_Version

For a prefix N that denotes the name of an entity, N'Compiler_Version yields the version of the compiler that was used to generate code for the unit containing the definition of N.

The entity named by N can be a program unit (package, subprogram, task, or generic), an object (variable, constant, named number, or parameter), a type or subtype (but not an incomplete type), or an exception.

The value returned by this attribute is of type string; for example, "1.6.1A".

This attribute can be used for run-time detection of incompatibilities in data representation. It typically is used when passing messages over a network to ensure that the reader and writer agree on how to interpret the message. See also Compiler_Key.

Dope_Address

For an object or type A, A'Dope_Address yields the address of the dope vector that describes A. The value is of type System.Address. If the object or type denoted by A has no dope vector, this value is System.Null_Address. Non-array objects and types are allowed with this attribute so that they may be applied to formal types inside a generic, where the nature of the actual type is not known statically.

This attribute can be used in conjunction with Dope_Size for retrieving information about the object, as when reconstructing the array when passing messages over a network. For information about dope vectors, see the Ada Runtime Guide.

Dope_Size

For an object or type A, A'Dope_Size yields the size in bits of the dope vector. The value is of type Universal_Integer. A value of zero is returned if the type to which A belongs is not an array type.

A positive value is always returned, whether or not the object denoted by A has a dope vector. Use 'Dope_Address to determine whether the dope vector actually exists.

This attribute can be used for retrieving information about the object, as when reconstructing the array when passing messages over a network. For information about dope vectors, see the Ada Runtime Guide.

Entry_Number

For a prefix E that denotes a task entry or generic formal subprogram, E'Entry_Number yields a Universal_Integer value that uniquely identifies the entity denoted by E.

Homogeneous

For a prefix T that denotes an access type, T'Homogeneous yields a Boolean value. The value returned is True if all objects in the collection will always have the same constraints. The converse, however, is not true.

Applying this attribute to a type other than an access type is a semantic error. It is most useful when applied to a generic formal access type.

Note that the attribute is a property of the type, not of the subtype. Thus, for any access type T, T'Homogeneous yields the same value as T'Base'Homogeneous.

For example:

At the implementation level, the attribute indicates whether constraint information is stored with allocated objects.

Ref

X'Ref generates a reference to the entity X. The definition is similar to the attribute X'Address.

For a prefix X that denotes an object, a program unit, a label or an enumeration literal, X'Ref yields the reference of the first of the storage units allocated to X; for a constant object with a static expression the value refers to the static expression. For a subprogram, the value refers to the constant pool associated with the corresponding body. For a label, the value refers to the machine code associated with the corresponding statement. For an enumeration literal the values refers to the position number. The value of this attribute is of type Operand defined in the package Machine_Code. It is only allowed within the context of a machine code procedure.

Type_Key

For a prefix T denoting a type declared in a library level package specification, T'Type_Key yields a string that uniquely identifies type T. This attribute typically is used when passing messages of a given type over a network to ensure that the reader and writer agree on the type to use when interpreting the message.


Tasks and Synchronization

Delay Statements, Duration, and Time

Shared Variables


Program Structure and Compilation Issues

Separate Compilation

Program Execution


Exceptions

Exception Handling

Suppressing Checks


Representation Issues

Note that in general, a compiler must either accept a representation clause and comply with it, or reject it if it finds that it cannot implement it. When we say that a representation clause is "allowed" or "supported", we mean that it is accepted by the compiler, and therefore, that the generated code complies with that clause.

Representation Items

Representation Attributes

Record Layout

The Package System

Native Apex Releases:
Cross/Embedded Apex Releases:

The location of these packages for the Apex cross products is dependent on the target processor and runtime variant. Use Table 49 to locate the desired Apex cross location. APEX_BASE and APEX_PROD_VERSION are set when Apex is invoked. Their values can be displayed using Tools > Session > Environment command.

Table 49 Location of Package System for Apex Cross (Ada 95)
Target
Location
Apex for Rational Exec
I386:
$APEX_BASE/ada/lrm.ss/i386.rx_i386.ada95.${APEX_PROD_VERSION}.rel
M68k:
$APEX_BASE/ada/lrm.ss/m68k.rx_mc68040.ada95.${APEX_PROD_VERSION}.rel
M68060:
$APEX_BASE/ada/lrm.ss/m68k.rx_mc68060.ada95.${APEX_PROD_VERSION}.rel
Mips1 (Big Endian):
$APEX_BASE/ada/lrm.ss/mips.rx_mips1b.ada95.${APEX_PROD_VERSION}.rel
Mips2 (Big Endian):
$APEX_BASE/ada/lrm.ss/mips.rx_mips2b.ada95.${APEX_PROD_VERSION}.rel
PowerPC:
$APEX_BASE/ada/lrm.ss/power.rx_ppc.ada95.${APEX_PROD_VERSION}.rel
RH32:
$APEX_BASE/ada/lrm.ss/rh32.rx_p3.ada95.2.4.2.rel

Apex for Tornado
M68060:
$APEX_BASE/ada/lrm.ss/m68k.vw_mc68060.ada95.${APEX_PROD_VERSION}.rel
Mips1 (Big Endian):
$APEX_BASE/ada/lrm.ss/mips.vw_mips1b.ada95.${APEX_PROD_VERSION}.rel
Mips2 (Big Endian):
$APEX_BASE/ada/lrm.ss/mips.vw_mips2b.ada95.${APEX_PROD_VERSION}.rel
PowerPC:
$APEX_BASE/ada/lrm.ss/power.vw_ppc.ada95.${APEX_PROD_VERSION}.rel

Apex for LynxOS
PowerPC:
$APEX_BASE/ada/lrm.ss/power.lx_ppc.ada95.${APEX_PROD_VERSION}.rel

The following packages are included in this location:

System
Address_to_Access_Conversions
Machine_Code
Storage_Elements
Storage_Pools

Machine Code Insertions

Unchecked Type Conversions

Storage Management

Pragma Restrictions

Streams


Predefined Language Environment

Package Standard

The Numerics Packages

External Files and File Objects

The Generic Package Storage_IO

Text Input-Output

The Package Command_Line


Interface to Other Languages

Interfacing Pragmas

The Pragma Interface

Interfacing with COBOL


Systems Programming

Access to Machine Operations

Interrupt Support

Preelaboration Requirements

Pragma Discard_Names

Task Identification and Attributes


Real-Time Systems

Task Priorities

Priority Scheduling

There are no implementation-defined execution resources.

Priority Ceiling Locking

Entry Queuing Policies

Preemptive Abort

Tasking Restrictions

Monotonic Time

POSIX-based Platforms (including Apex Embedded for LynxOS)

Time_Unit is the POSIX time base: 1 nanosecond. Time and Time_Span are both implemented as 64-bit integers, and Clock returns the current time as reported by the POSIX clock_gettime() function, converted into a 64-bit count of nanoseconds from the UNIX epoc (Midnight, December 31, 1969). Time_First is 2**63 nanoseconds before the UNIX epoch, or approximately September 22, 1677; Time_Last is 2**63-1 nanoseconds after the UNIX epoch, or approximately March 10, 2262. Time_Span_First represents -2**63 nanoseconds, or approximately -9.22E9 seconds; Time_Span_Last represents 2**63-1 nanoseconds, or approximately 9.22E9 seconds.

Tick is the value returned by the POSIX clock_getres() function, converted to an Ada.Real_Time.Time value.

Apex Embedded platforms (except LynxOS)

Both Time_Unit and Tick are configurable on embedded platforms to better correspond with hardware support for time and delays. The source code to Ada.Real_Time and the configuration package Apex_Real_Time_Conf should be consulted for these values, as described in Chapter 13 "Configuring the User Library" of "Using the Ada Runtime".

Delay Accuracy

POSIX-based Platforms (including Apex Embedded for LynxOS)

The delay until statement will not block if the value of the statement argument is not greater then the value of Clock at the point in the runtime system where blocking occurs. Between the time that the delay until statement commences and the point at which this test is made, programs run under all of the POSIX-based platforms described by this document may experience preemption by other processes for an arbitrary period of time. For this reason, it is impossible to place an upper bound on the difference between the argument to a delay statement and the value of Clock at the time that the statement starts to execute that will result in actual blocking of the task.

Other Optimizations and Determinism Rules


Distributed Systems

Partitions

Consistency of a Distributed System

Remote Subprogram Calls

Partition Communication Subsystem


Information Systems

The Package Decimal

Edited Output for Decimal Types


Numerics

Complex Arithmetic

Numeric Performance Requirements


Safety and Security

Table 51 describes the handling of each restriction as required in Annex H, section H.2.

Table 51 Annex H - Handling of Restrictions
Restriction
Handling of violation
No_Task_Hierarchy
checked at installation
No_Nested_Finalization
no support
No_Abort_Statements
checked at installation
No_Terminate_Alternatives
checked at installation
No_Task_Allocators
checked at installation
No_Implicit_Heap_Allocations
no support
No_Dynamic_Priorities
checked at installation
No_Asynchronous_Control
checked at installation


Max_Select_Alternatives
checked at installation
Max_Task_Entries
checked at installation
Max_Protected_Entries
cchecked at installation
Max_Storage_At_Blocking
no support
Max_Asynchronous_Select_Nesting
checked at installation (if value is 0)
Max_tasks
no support


No_Protected_Types
checked at installation
No_Allocators
checked at installation
No_Local_Allocators
checked at installation
No_Unchecked_Deallocation
checked at installation
Immediate_Reclamation
no support
No_Exceptions
hecked at installation does not currently cause runtime suppression of checks


No_Floating_Point
no support
No_Fixed_Point
no support
No_Unchecked_Conversion
checked at installation
No_Access_Subprograms
checked at installation
No_Unchecked_Access
checked at installation
No_Dispatch
checked at installation
No_Io
checked at installation
No_Delay
checked at installation
No_Recursion
no support
No_Reentrancy
no support


No_Requeue_Statements
checked at installation
No_Tasking
checked at installation

Documentation Of Implementation Decisions

Reviewable Object Code

Safety and Security Restrictions


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2004, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS