![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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
- Lexical Elements
- Declarations and Types
- Names and Expressions
- Tasks and Synchronization
- Program Structure and Compilation Issues
- Exceptions
- Representation Issues
- Predefined Language Environment
- Interface to Other Languages
- Systems Programming
- Real-Time Systems
- Distributed Systems
- Information Systems
- Numerics
- Safety and Security
GeneralScope
- Whether or not each recommendation given in Implementation Advice is followed. See 1.1.2(37).
- 2.8 (16): Semantic effect of implementation-defined pragmas. The implementation-defined pragma Assert has a semantic effect (it may cause an exception to be raised).
- 3.5.2 (5): Recommendations concerning alternative interpretations of Character and Wide_Character. The implementation does not support a mode with alternative interpretations for Character and Wide_Character.
- 3.5.4 (28): Recommendations concerning Long_Integer. All targets define three signed integer types in package Standard: Short_Integer, Integer, and Long_Integer. Short_Integer is 16 bits in size, Integer is 32 bits, and Long_Integer is either 64 bits or 32 bits, depending on the target hardware.
- 3.5.4 (29): Recommendations for modular types. Modular types are supported as recommended.
- 3.5.5 (8): Behavior when S'Pos is given a bad value. Program_Error is raised as recommended when `POS is given a bad value.
- 3.5.7 (17): Long_Float should be supported if the hardware supports 11 or more digits of precision; types other than Float and Long_Float are not recommended in Standard. Long_Float is supported with a precision of 15 digits. Short_Float is defined in Standard, and has the same precision as Float.
- 3.6.2 (11): Representation of Arrays. As recommended, arrays are stored in row-major order.
- 9.6 (30): Duration'Small should be no greater than 100 microseconds. Duration'Small is less than or equal to 100 microseconds.
- 10.2.1 (12): Representation of types declared in preelaborated packages. Types declared in preelaborated packages have the same representation in every elaboration of a given version of the package.
- 11.4.1 (19): Recommendations for Exception_Message and Exception_Information. The implementation does not provide information useful for debugging from Exception_Message and Exception_Information.
- 11.5 (28): Minimization checking code when checks are suppressed. Any code that would have been generated to perform a check is omitted when the check is suppressed, unless the compiler can determine that the check would certainly fail, in which case it generates code to raise the appropriate exception unconditionally.
- 13.1 (21): Recommended support for representation items. The implementation complies with the recommendations of paragraphs 22-24.
- 13.2 (6): Storage minimization due to pragma pack. Storage allocated to objects is minimized as recommended.
- 13.3 (14): Address attribute of an array. As recommended, X'Address for an array X yields the address of the first component of X, never the address of bounds information.
- 13.3 (15): Support for Address attribute for objects. As recommended, useful values of X'Address are provided when X is either an aliased object, or of a by-reference type, or an entity whose address has been specified.
- 13.3 (17): Support for Address attribute for subprograms. Address clauses are not supported for imported subprograms
- 13.3 (18): Allocation of objects that are aliased or of a by-reference type. Objects and subcomponents that are aliased or of by-reference types are allocated on storage element boundaries, as recommended.
- 13.3 (19): Optimizations based on alias detection. As recommended, no optimizations based on assumptions of no aliases are performed on objects for which the address is specified, or if it is imported or exported.
- 13.3 (29): Support for Alignment attribute for subtypes. As recommended, subtype Alignments that are factors and multiples of the number of storage elements per word subject to the constraints of paragraphs 31-32 are supported.
- 13.3 (33): Support for Alignment attribute for objects. The only value supported is the default alignment for the subtype of the object.
- 13.3 (42): Support for Size attribute for objects. The only value supported is the default size for the subtype of the object.
- 13.3 (50): Support for Size attribute for subtypes. The size of Aliased objects of the subtype may be greater than the size of the subtype.
- 13.3 (54): Support for Size attribute for subtypes. As recommended, the implementation supports the Size attribute for subtypes as per paragraph 55-56
- 13.3 (71): Support for Component_Size attribute. The Component_Size attribute is not currently supported.
- 13.4 (9): Support for enumeration representation clauses. As recommended, internal codes in the range System.Min_Int .. System.Max_Int are supported. Enumeration representation clauses are supported for Boolean types.
- 13.5.1 (17): Support for record representation clauses. As recommended, the implementation supports record_representation_clauses as per paragraphs 18-22.
- 13.5.2 (5): Storage place attributes. As recommended, the implementation supports Storage Place attributes to reflect the place of the actual data, when the component is represented using a form of a pointer.
- 13.5.3 (7): Support for nondefault bit ordering. Since Word_Size > Storage_Unit on all platforms, the implementation only supports the default bit ordering.
- 13.7 (37): System.Address. The type System.Address is private, as recommended.
- 13.7.1 (16): System to reflect target environment. As recommended, operations in System and its children reflect the target environment semantics as closely as is reasonable.
- 13.9 (14): Unchecked_Conversion. As recommended, the size of an array object does not include its bounds.
- 13.11 (23): Implicit allocation of heap storage. The following operations implicitly require heap-storage allocation: creation of dynamic-sized objects and values in a static scope and creation of dynamic-sized objects and values in a separate non-generic package body
- 13.11.2 (17): Unchecked_Deallocation. As recommended, Free does actually reclaim storage for the standard storage pool.
- 13.13.2 (17): Streams. As recommended, when a stream element is the same size as a storage element, the normal in-memory representation is used by Read and Write for scalar objects, and otherwise they use the smallest number of stream elements needed to represent all values in the base range of the scalar type.
- Capacity limitations of the implementation. See 1.1.3(3)
Capacity limits of the implementation include:
Maximum number of discriminants in a known discriminant part 256
Maximum number of generic parameters in a generic formal part 256
Maximum block (or other naming scope) nesting depth 250
- Variations from the standard that are impractical to avoid given the implementation's execution environment. See 1.1.3(6)
There are no variations from the standard that were impractical to avoid.
- Which code_statements cause external interactions. See 1.1.3(10).
Lexical ElementsCharacter Set
- The coded representation for the text of an Ada program. See 2.1(4).
Ada programs are represented as text files encoded in ASCII extended with the Latin-1 graphic characters A0-FF and the Latin-1 nongraphic characters 80-9F.
- The control functions allowed in comments. See 2.1(14).
A comment consists of two dashes followed by any valid character, up to the first format effector NL (0A), VT (0b), NP (0c), or CR (od).
Lexical Elements, Separators, and Delimiters
- The representation for an end of line. See 2.2(2).
A line is terminated by any of the format effectors NL (0A), VT (0b), NP (0c), or CR (0d). However, only the line terminator NL causes the line number counter, which is displayed in error messages, to be incremented.
- Maximum supported line length and lexical element length. See 2.2(15).
Lexical elements must be no longer that 254 characters. The line length is limited only by available memory.
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.
- Implementation-defined pragmas. See 2.8(14).
The following implementation-defined pragmas have been implemented, in addition to those specified in the Ada 95 Reference Manual.
Pragma Api
Designates a compilation unit as belonging to the user-visible portion of an API. The syntax is:
pragma API (api_name);
- Api_Name: An identifier obeying Ada syntax rules that names the API.
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:
pragma ASSERT ([PREDICATE =>]boolean_expression
);
- Predicate: The Boolean expression to be evaluated at run time.
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:
pragma Calling_Convention( [Entity =>]local_name
[,attribute1
=>value1
,] [,attribute2
=>value2
,] ...)
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.
- Floating_Point_Status_Preserve => True | False: Tells the compiler whether to preserve (that is, save and restore) the floating point status register upon entry/exit of the subprogram body. Note that this is the only attribute that can be applied to both imported and exported routines.
True Save current the floating-point control state.
Establish floating-point control state for C
(from external __FP_CONTROL_FOR_C)
Make the CALL
Restore floating point state
False CALL [Default]
True Save the floating-point state in prologue
Re-establish floating-point control state for Ada
(from external __FP_CONTROL_FOR_ADA). Restore floating point in epilogue
False Nothing [Default]
The global variables __FP_CONTROL_FOR_ADA and __FP_CONTROL_FOR_C are initialized by the Ada runtime system to the value of the FLOATING_POINT_CONTROL and C_FLOATING_POINT_CONTROL fields of the user's configuration table, respectively.
The expected default IEEE floating-point behavior may differ between the Ada and C environments, so that the FP control bits in the status (or control) register need to be modified when making the transition for Ada to C, or vice versa, and then restored upon return.
For historical reasons, the attribute name is a slight misnomer. The first implementation was for a target where the floating-point control bits were in the floating-point STATUS register, and only specified that the status register should be PRESERVED (saved/restored) across the language boundary (another mechanism was used to establish the correct FP control bits in the foreign environment).
Note that Floating_Point_Status_Preserve only affects the floating point status (control) register, and not any other floating-point registers. Other FP registers should be saved/restored according to the normal calling conventions.
- Stack_Limit => None | Defeated | Call_Runtime: Tells the compiler how to initialize the stack limit upon entering the subprogram.
If Ada code is to be entered from a C environment, it is necessary that all the Ada code reachable from C have storage (stack limit) checks suppressed, or that a valid stack limit be establish upon entry to the Ada code. If Stack_Limit => None is used, it is assumed that storage checks have been suppressed on all Ada code reachable from this routine. Typically, this means the routine should be a leaf, or have a limited, well-defined, call graph. Stack_Limit => Defeated, sets the stack_limit to a maximal value. This effectively disables storage checks without actually suppresses. Stack_Limit => Call_Runtime is the default. Upon entry to the interfaced routine, the stack limit re-loaded with the correct value by means of a special call to the Ada runtime.
- Abort_Deferred => True | False: Tells the compiler whether to defer aborts when the subprogram is called.
True ts_abort_defer
CALL
ts_abort_restore
False call [Default]
The middle pass generates the calls to ts_defer_abort and ts_undefer_abort immediately before and after the call to the imported subprogram.
An exception handler needs to be wrapped around the call to make sure aborts get undeferred properly. Note that the C routine we are calling could call back into Ada which could then raise an exception.
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.
pragma Import (C, <subprogram>); pragma Calling_Convention (<subprogram>, Floating_Point_Status_Preserve => True);
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.
The following contains examples of pragma Calling_Convention for both imported and exported subprograms.
with System; package Ex is -- I. Example Imported subprograms: function Write (Fd : Integer; Buffer : System.Address; Size : Integer) return Integer; -- Nothing special do the default stuff. function Malloc (Size : Integer) return System.Address; pragma Import (C, Malloc); pragma Calling_Convention (Malloc, Abort_Deferred => True); -- If the application supports abort this call must be protected. procedure Graph; pragma Import (C, Graph); pragma Calling_Convention (Graph, Floating_Point_State_Preserve => True); -- This procedure uses floating-point. -- The Import pragma indicates that calling convention is C so the -- floating-point unit must be initialized correctly for a C function -- The C function may do other damage to the floating-point state so -- the floating-point state must be saved before making a call to -- graph and restored afterwards -- -- The program that uses graph will not be using aborts or ATC so -- the overhead required for abort deferral is not required
-- II. Example Exported subprograms: procedure Normal_Ada_Procedure; pragma Export (Normal_Ada_Procedure, C); pragma Calling_Convention (Normal_Ada_Procedure, Stack_Limit => Call_Runtime); -- Default case. This procedure is called from C but it is assumed that -- it is on the thread of an ada task. The runtime is called to -- initialize the stack limit.
procedure Normal_Ada_Float_Procedure; pragma Export (Normal_Ada_Float_Procedure, C); pragma Calling_Convention (Normal_Ada_Float_Procedure, Stack_Limit => Call_Runtime, Floating_Point_State_Preserve => True); -- Normal procedure that is going to do floating-point. -- Save the C floating-point state and initialize correctly for ada. -- Restore C floating-point state before returning.
procedure No_Tasking_Procedure; pragma Export (No_Tasking_Procedure, C); pragma Calling_Convention (No_Tasking_Procedure, Stack_Limit => Defeated); -- This procedure is called from C but from a thread that does not -- contain an ada task. The stack limit will be loaded with 0 -- (stack_limit'max) so that stack limit checking code will not generate -- exceptions.
procedure Low_Level_Ada_Procedure; pragma Suppress (Storage_Check, On => Low_Level_Ada_Procedure); pragma Export (Low_Level_Ada_Procedure, C); pragma Calling_Convention (Low_Level_Ada_Procedure, Stack_Limit => None); -- This procedure should not initialize the stack limit register -- Stack limit checking has been disabled. -- The floating-point must not be touched. end Ex;Pragma Collection_Policy
Controls memory allocation for the collection designated by an access type. The syntax is:
pragma COLLECTION_POLICY (ACCESS_TYPE =>access_type
, INITIAL_SIZE =>integer_expression
[, EXTENSIBLE =>boolean_expression
] [, EXTENSION_SIZE =>integer_expression
]);
- Access_Type: The access type on which to perform storage management.
- Initial_Size: The size in storage units of the initial collection created for an access type. A negative value is treated as zero. The default value is zero; this default can be changed using pragma Main.
- Extensible: Specifies whether the collection can be extended. If True, sets the extension size to the default or specified value of Extension_Size; otherwise, Extension_Size is ignored. The default value is True.
- Extension_Size: The minimum number of storage units by which the collection will be extended, when needed, if it is extensible. A negative value is treated as 0. The default value is 2,048 bytes. A default extension size for all collections can be set using pragma Main.
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.
- The arguments must be specified using named association.
- Only one Collection_Policy pragma is allowed per access type. If more than one is specified, the first is applied and the rest are ignored.
- When an access type has an associated 'Storage_Size clause, any Collection_Policy pragma for that access type is ignored. This occurs because a declaration of the form:
for X'STORAGE_SIZE use size;
is functionally equivalent to:
pragma COLLECTION_POLICY (ACCESS_TYPE => X, INITIAL_SIZE => size, EXTENSIBLE => FALSE);
- If Initial_Size is nonpositive and Extensible is False, attempting to execute an allocator of the access type raises the Storage_Error exception.
Pragma Export_Elaboration_Procedure
Defines a global symbolic name for the elaboration procedure of a given compilation unit. The syntax is:
pragma EXPORT_ELABORATION_PROCEDURE ([EXTERNAL =>] "external_name");
- External: The global symbolic name associated with the elaboration procedure. EXTERNAL is a string literal.
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.
- This pragma must appear immediately following the compilation unit to which it refers.
Pragma Implicit_Code
Controls the generation of implicit code. The syntax is:
pragma IMPLICIT_CODE (ON | OFF)
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.
pragma LICENSE ([FEATURE =>] manifest string-valued expression, [, [VERSION =>] unbased floating-point literal ]);
- Feature: The name of the feature license required.
- Version: An unbased floating point literal giving the version number of the feature license.
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.
pragma License ("Acme_Database", 3.0);
Pragma Linker_Options
Passes arguments to the target linker. The syntax is:
pragma Linker_Options (manifest_string_expression)
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:
pragma MAIN [ ([COLLECTION_INITIAL_SIZE => integer_expression,] [COLLECTION_EXTENSION_SIZE => integer_expression,] [DBG_SUSPEND_DISABLED_FLAG => boolean_expression,] [EXCEPTION_STACK_SIZE => integer_expression,] [FAST_RENDEZVOUS_ENABLED => boolean_expression,] [HEAP_EXTEND => integer_expression,] [HEAP_SIZE => integer_expression,] [IDLE_STACK_SIZE => integer_expression,] [NONBLOCKING_IO =>boolean_expression
,] [NUMERIC_SIGNAL_ENABLED => boolean_expression,] [POSIX_COMPLIANT =>boolean_expression
,] [SIGNAL_TASK_STACK_SIZE => integer_expression,] [STACK_SIZE =>integer_expression
,] [STORAGE_SIGNAL_ENABLED => boolean_expression,] [TASK_PRIORITY_DEFAULT =>priority_expression
,] [TASK_STACK_SIZE_DEFAULT =>integer_expression
,] [TASK_STORAGE_SIZE => integer_expression,] [TIME_SLICE =>duration_expression
,] [TIME_SLICE_PRIORITY => integer_expression,] [TIME_SLICING_ENABLED => boolean_expression,] [WAIT_STACK_SIZE => integer_expression,] [ZERO_STACKS_ENABLED => boolean_expression,] [TRACE_BUFFER_SIZE => integer_expression]);
All expressions must be static; all integer expressions must be nonnegative.
- Collection_Extension_Size: An integer expression giving the minimum number of storage units by which an extensible collection will be extended when needed. This value can be overridden for individual access types using pragma Collection_Policy. The default value is zero.
- Collection_Initial_Size: An integer expression giving the default size in storage units of the initial collection that is created for an access type. This value may be overridden for individual access types using pragma Collection_Policy. The default value is zero.
- Dbg_Suspend_Disabled_Flag: Controls how the debugger behaves when a multitasking program takes a breakpoint. If True, only the task taking the breakpoint stops; if False, all tasks stop.
- Exception_Stack_Size: An integer expression giving the number of storage units set aside at the bottom of each tasks's stack for exception unwinding. The default value for this argument is set correctly and it will normally not require modification. Setting this value incorrectly could cause the program to be erroneous.
- Fast_Rendezvous_Enabled: A boolean expression indicating whether the fast rendezvous optimization is to be used. This optimization causes a rendezvous to be executed in the context of the calling task when the accepting task is already waiting. The default value is True; this value is typically set to False only when using Multiprocessor Ada.
- Heap_Extend: An integer expression that specifies the number of storage units by which the heap is to be extended when needed.
- Heap_Size: An integer expression that specifies how much space to allocate for the heap, in storage units, when the main unit begins execution. If this argument is specified, no additional space is allocated to the heap after initialization; requests for more heap space raise Storage_Error.
If not specified, heap space is allocated dynamically as needed until space is exhausted and Storage_Error is raised.
- Idle_Stack_Size: An integer expression giving the size of the stack for the idle task in storage units. The default value for this argument is set correctly and it will normally not require modification. Setting this value incorrectly could cause the program to be erroneous.
- Nonblocking_Io: Specifies whether I/O should block all tasks in the program. If True, only the task performing the I/O blocks; if False, the entire program blocks. The default is False.
- Numeric_Signal_Enabled: Specifies whether the program uses the UNIX signal SIGFPE to catch numeric errors. The default is True. If False is specified, the program will no longer conform to Ada semantics for floating point operations, but this can be useful when calling code written in other languages that use or ignore SIGFPE.
- Posix_Compliant: Specifies whether certain behavior described by the IEEE Portable Operating System Interface (POSIX) is required. If True, the following operational characteristics of programs compiled and linked under Apex are affected:
- The program can control only those UNIX signals explicitly allowed by POSIX.5 3.3.3.1 (those not "reserved for the Ada implementation").
- The program cannot install an interrupt-entry task to handle UNIX signals that the runtime system uses, nor can it install both an interrupt-entry task and an Ada procedural signal handler for the same signal (POSIX.5 3.3.2.1(963)).
The default values for the Form-parameter fields in the Ada-predefined I/O packages are the POSIX.5 values rather than the Apex values.
- Signal_Stack_Task_Size: An integer expression that specifies the size of the signal stack in storage units. The Rational Ada runtime system creates a signal stack for each task entry that is bound to an interrupt. The default value for this argument is set correctly and it will normally not require modification. Setting this value incorrectly could cause the program to be erroneous.
- Stack_Size: An integer expression that specifies the size of the main task stack in storage units. This quantity excludes the space at the bottom of the stack for exception handling, which can be expressed with the Exception_Stack_Size argument of this pragma.
- Storage_Signal_Enabled: Controls whether the runtime system catches segmentation violations (SIGSEGV) and turns them into Storage_Error. The default is False.
- Task_Priority_Default: An expression of typeSystem.Priority that specifies the priority for any task without a pragma Priority. The default value depends on the type of task as follows:
Main task default priority max_priority/2 (= 49 for Apex)
Other task default priorities same as activating task
This argument is ignored by the compiler.
- Task_Stack_Size_Default: An integer expression that specifies the size, in storage units, of the stack for any task without a 'Storage_Size representation clause.
- Task_Storage_Size: Specifies the size in bytes of the area set aside in the task control block for user storage. The VADSexec services Allocate_Task_Storage and Get_Task_Storage manage this area in the task control block. The Ada 95 task attributes as described in the system's programming annex and the rts_vads_exec subsystem manage this area of the task control block.
- Time_Slice: A nonnegative expression of type Standard .Duration that determines the quantity of time to allocate to an executing task. By default, or if the value is zero, no time slicing is used. This has an effect only in conjunction with preemptive scheduling; otherwise, it is ignored.
- Time_Slice_Priority: If time slicing is enabled, it applies only to tasks whose priority is less than or equal to this value.
- Time_Slicing_Enabled: Controls whether time slicing occurs. The default is True.
- Trace_Buffer_Size: The size in trace_buffer records (events) of the trace buffer used with the Apex Tasking Logic Analyzer. These records vary in size from 8 words to 14 words, depending on the Apex version and target. v_i_trace.1.ada contains the definition.
- Wait_Stack_Size: In a fast rendezvous, the accepting task saves its register context, switches to a wait stack, and waits. Eventually, the calling task restores and uses the accepting task's saved register context. Wait_Stack_Size is an integer expression that specifies how much stack is needed when the accepting task switches from its normal task stack to the special wait stack it uses to call a kernel service to block itself. This value is only used if Fast_Rendezvous_Enabled is True. Setting the Wait_Stack_Size to zero also disables the fast rendezvous optimization. The default value for this argument is set correctly and it will normally not require modification. Setting this value incorrectly could cause the program to be erroneous.
- Zero_Stacks_Enabled: At program startup, all the memory to be used for task stacks is initialized. The command name uses "zero", though memory is actually set to the fill value for the target. With the following exceptions, the value is 0. For LynxOS, the fill value is 16#FF#, and for VxWorks it is 16#EE#. If tasks are dynamically terminated and recreated, the stack area for recreated tasks is not initialized. This can lead to erroneous stack usage information displayed by the debugger's "lt use" command. Zero_Stacks_Enabled is set to True to guarantee that stacks of dynamically created tasks are initialized. Since it takes extra time to initialize the stack area, ZERO_STACKS_ENABLED is normally only set to True when used in conjunction with "lt use" for dynamically created tasks.
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:
- Causes the unit to be linked automatically if it is in a directory or view for which you have requested linking. Main units without pragma Main are not linked unless explicitly requested.
- Permanently specifies the various properties and sizes given in its arguments.
procedure Show_Main is begin Do_Something; end Show_Main; pragma Main (Stack_Size => 10*1024); --Change to 10 Kb
Pragma Optimize_Code
Specify whether the compiler should attempt to optimize through the machine code insertions. The syntax is:
pragma Optimize_Code (on | off);
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:
pragma Suppress_Elaboration_Checks;
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;
package Watchdog is procedure Spot; procedure Bruno; end Watchdog; pragma Suppress_Elaboration_Checks;
package Watchdog is procedure Spot; procedrue Bruno; pragma Suppress (Elaboration_Check, On => Spot); pragma Suppress (Elaboration_Check, On => Bruno); end Watchdog;
- Effect of pragma Optimize. See 2.8(27).
Pragma Optimize currently has no effect. Optimization is controlled by the OPTIMIZATION_LEVEL and OPTIMIZATION_OBJECTIVE switches.
Declarations and TypesScalar Types
- The sequence of characters of the value returned by S'Image when some of the graphic characters of S'Wide_Image are not defined in Character. See 3.5(37).
The sequence of characters returned by S'Image for a character literal which is not part of the type Character is: "\uABCD" where ABCD is the hexadecimal representation of the position of the character in type Wide_Character. For instance:
Greek_Capital_Letter_Alpha : constant Wide_Character := Wide_Character'Val (16#0391#); Image : constant String := Wide_Character'Image (Greek_Capital_Letter_Alpha); -- Image is the string "\u0391"
- The predefined integer types declared in Standard. See 3.5.4(25).
The following Integer types have been defined in Standard:
Short_Short_Integer
Short_Integer
Integer
Long_IntegerThree of these Integer types have the same definition on all Apex platforms:
type Short_Short_Integer is range -(2 ** 7) .. (2 ** 7) - 1; type Short_Integer is range -(2 ** 15) .. (2 ** 15) - 1; type Integer is range -(2 ** 31) .. (2 ** 31) - 1;
The definition of type Long_Integer is dependent on the Apex target platform.
For Sun SPARC V8, HP-PA, and IBM:
type Long_Integer is range -(2 ** 31) .. (2 ** 31) - 1;
For DEC Alpha, SGI, and Sun SPARC V9 on Solaris 7 or greater:
type Long_Integer is range -(2 ** 63) .. (2 ** 63) - 1;
In all cases, the anonymous type *Root_Integer* (see RM95 3.4.1(8)) is defined to have the same bounds as Long_Integer.
- Any nonstandard integer types and the operators defined for them. See 3.5.4(26).
No nonstandard integer types are defined in Standard.
- Any nonstandard real types and the operators defined for them. See 3.5.6(8).
No nonstandard real types are defined in Standard.
- What combinations of requested decimal precision and range are supported for floating point types. See 3.5.7(7).
The requested decimal precision for a floating point type may not exceed 15 digits. The bounds must lie in the range (2 ** 1024) - (2 ** 971) .. (2 ** 1024) - (2 ** 971). Equivalently, the digits and bounds specified in a floating point type definition may not exceed those of LONG_FLOAT. All combinations of range and precision which satisfy this constraint are supported.
- The predefined floating point types declared in Standard. See 3.5.7(16).
The predefined floating point types declared in Standard are:
type Short_Float is digits 6 range (2.0 ** 104) - (2.0 ** 128) .. (2.0 ** 128) - (2.0 ** 104); type Float is digits 6 range (2.0 ** 104) - (2.0 ** 128) .. (2.0 ** 128) - (2.0 ** 104); type Long_Float is digits 15 range (2.0 ** 971) - (2.0 ** 1024) .. (2.0 ** 1024) - (2.0 ** 971);- The small of an ordinary fixed point type. See 3.5.9(8).
The largest power of two that is less than or equal to the DELTA of a fixed point type is selected as the SMALL of an ordinary fixed point type.
- What combinations of small, range, and digits are supported for fixed point types. See 3.5.9(10).
For Sun SPARC, HP-PA, SGI, and IBM, 32 bits of precision (in the sense of RM95 3.5.9(20)) are supported. For Digital UNIX, 64 bits of precision are supported.
Type Extensions
- The result of Tags.Expanded_Name for types declared within an unnamed block_statement. See 3.9(10).
A unique name is implicitly assigned to each unnamed block statement. The unique name is based on the lexical placement of the block statement. For example if a block statement appears as the third statement in the body of a procedure named "PPP" its implicit, unique name is "PPP.3S". The full expanded name of a tagged type thus includes the implicit, unique names of all (if any) enclosing block statements.
Names and Expressions
- Implementation-defined attributes. See 4.1.4(12).
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.
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:
"/apex_home/keys/ada_rational_rs6k_aix".
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.
type T1 is access String (1..10);-- T1'Homogeneous=True type T2 is access String; -- T2'Homogeneous=False type T3 is new T2 (1 .. 10); -- T3'Homogeneous=False type T4 is new T1; -- T4'Homogeneous=True
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 SynchronizationDelay Statements, Duration, and Time
- Any implementation-defined time types. See 9.6(6).
There are no implementation-defined time types.
- The time base associated with relative delays. See 9.6(20).
The time base associated with relative delays is that corresponding to Ada.Calendar.Time.
- The time base of the type Calendar.Time. See 9.6(23).
The time base of the type Ada.Calendar.Time is the same as that of Ada.Real_Time.Time.
- The timezone used for package Calendar operations. See 9.6(24).
The time zone used for Ada.Calendar.Split and Ada.Calendar.Time_Of is that of the underlying operating system, as implemented by the gettimeofday() and localtime() operations, at the time of program initialization. This time zone remains constant throughout the execution of the program.
- Any limit on delay_until_statements of select_statements. See 9.6(29).
The delay_until_statements of select_statements can accept any value that can be represented by Ada.Calendar.Time or Ada.Real_Time.Time.
Shared Variables
- Whether or not two nonoverlapping parts of a composite object are independently addressable, in the case where packing, record layout, or Component_Size is specified for the object. See 9.10(1).
If packing, record layout, or component size is specified for a composite object, then nonoverlapping parts of that object are generally not independently addressable.
Program Structure and Compilation IssuesSeparate Compilation
- The representation for a compilation. See 10.1(2).
A compilation is represented as an ASCII file containing the concatenation of the text of the individual compilation units
- Any restrictions on compilations that contain multiple compilation_units. See 10.1(4).
In a multi-compilation unit compilation, if there is more than one compilation unit with the same name, each subsequent compilation unit replaces the former one in the library. Hence, it is not effectively possible to have more then one compilation unit with a given name in a compilation.
- The mechanisms for creating an environment and for adding and replacing compilation units. See 10.1.4(3).
The "environment" described in the AARM maps onto the Apex "view". A new view is created with the Apex create_working command. Compilation units are introduced into a view by executing the command rada -compile sss, where sss is the name of a file containing the source text of the units to be introduced.
Program Execution
- The manner of explicitly assigning library units to a partition. See 10.2(2).
Every partition has a main program; a library unit is (implicitly) assigned to a partition if and only if it is in the closure of the main program of the partition. No other mechanism for assigning library units to partitions is supported.
- The implementation-defined means, if any, of specifying which compilation units are needed by a given compilation unit. See 10.2(2).
A given compilation unit "needs" (in the sense of RM95 10.2(2)) only the units listed in RM 95 10.2(3-6). No implementation-specific dependencies are introduced.
- The manner of designating the main subprogram of a partition. See 10.2(7).
A parameterless procedure or a parameterless integer-valued function may be specified as the argument to the apex link command. For example,
apex link foo.2.ada
This designates the given subprogram as the main program for a partition and performs the associated compilation and linking.
- The order of elaboration of library_items. See 10.2(18).
If the ELABORATION_ORDER_LISTING switch is set to True in the view containing a main program, say foo.2.ada, then linking the main program will create a file foo.2.elab_order which contains a complete listing of the elaboration order of the library_items comprising the partition of the main program.
- Parameter passing and function return for the main subprogram. See 10.2(21).
The result of a main subprogram which is an integer-valued function is returned as a exit status value. Main subprograms must be parameterless.
- The mechanisms for building and running partitions. See 10.2(24).
Support for partitions is currently limited to a traditional "main program" model. Partitions are "built" by linking a main program (e.g. using the apex link command) and are "run" by invoking the resulting executable file.
- The details of program execution, including program termination. See 10.2(25).
The set of partitions comprising a program is a set of size one.
- The semantics of any nonactive partitions supported by the implementation. See 10.2(28).
Nonactive partitions are not supported by the implementation.
ExceptionsException Handling
- The information returned by Exception_Message. See 11.4.1(10).
For a raise_statement with an exception_name, Exception_Message returns a null string.
- The result of Exceptions.Exception_Name for types declared within an unnamed block_statement. See 11.4.1(12).
Unlabeled blocks are given internal labels. This label is the Apex statement number, which corresponds to those used by the debugger, followed by the letter `S'. This label is then used in constructing the result of Exception_Name as if it had been the block's explicitly given label.
- The information returned by Exception_Information. See 11.4.1(13).
Exception_Information returns a string comprised of the exception occurrence's exception name followed by the string literal " raised at ", followed by the value of the program counter in hexadecimal where the exception was first raised (reraises do not affect this value).
Suppressing Checks
- Implementation-defined check names. See 11.5(27).
Representation IssuesNote 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
- The interpretation of each aspect of representation. See 13.1 (20).
The implementation does not interpret any of the representation aspects in an implementation-specific manner. All representation aspects have their language defined, canonical meaning.
- Any restrictions placed upon representation items. See 13.1(20).
The implementation places the following restrictions upon representation items specifying the size of an object, subtype or component (`Size, `Component_Size, and record representation clauses):
- The size specified for a floating point entity must match the size of a floating point format supported by the target architecture.
- The size specified for a discrete or fixed point entity must not exceed the word-size of the target architecture.
- The size specified for an access-to-object or task entity must not exceed the address-size of the target architecture.
- The size specified for an access-to-subprogram entity must match the size of a subprogram descriptor of the target architecture.
The implementation places the following restrictions upon representation items specifying, explicitly or implied, the alignment of an object, subtype, or component (`Alignment, `Address, and record representation clauses):
- An explicit alignment may only be specified as a power of two in the range 0..16.
- The alignment specified for a tagged or access-to-subprogram entity must not be less than the natural alignment of an address on the target architecture.
- The alignment specified for an aliased or by-reference entity must be no less than the natural alignment of the entity.
Note: In this discussion, the alignment is expressed in bytes.
In Ada 95, the Ada 83 construct named alignment_clause, has been renamed at_clause, and moved to the Obsolescent Features annex. The recommended way to control alignments in Ada 95 is through an attribute_definition_clause for the Alignment attribute. The syntax for attribute_definition_clauses is given in RM95 13.3(2), and the semantics of specifying the Alignment attribute are defined in RM95 13.3(25-26). (Note that an attribute_definition_clause for the Alignment attribute is called an alignment clause in RM95; reusing the Ada 83 terminology for an entirely different construct is only making things a bit more confused; in the rest of this discussion, the phrase "alignment clause", is used with its Ada 95 meaning.)
The syntax of an alignment clause is:
for local_name'Alignment use expression;
where local_name must denote a first subtype or an object. Here is an example with a first subtype:
type Rec is record C1 : Boolean; C2 : Integer; C3 : Character; end record; for Rec'Alignment use 8;
and here is an example with an object:
Some_Rec : Rec := (C1 => True, C2 => 2, C3 => 'z'); for Some_Rec'Alignment use 2 ** 10;
The semantics of specifying the Alignment attribute for a (first) subtype are essentially the same as for Ada 83; the address of each and every object allocated under control of the implementation must be a multiple of the alignment specified for its subtype. In practice, because of the need to properly align objects allocated on the stack or on the heap, this means that only "small" value can be specified. The actual limits for Apex are as follows:
Table 46 Type Alignment Limits - Ada 95
4
8
8
8
8
8
4
8
Specifying the Alignment attribute for an object, on the other hand, only affects the given object. If the object is allocated on the stack or on the heap, the same limitations as for types apply. However, if the object is declared in a library-level package, it is statically allocated, and its address is determined by the target linker. This makes it possible to use linker directives to control alignment. As a consequence, alignment is limited only by the particular linker being used, rather than the instruction set in use. The actual limits for Apex are as follows:
Table 47 Object Alignment Limits - Ada 5
16
216
8
The implementation does not support representation items applying to structured objects, subtypes, or components which have non-static or discriminant-dependent constraints.
Length clauses are supported by this implementation as follows:
- Length clauses are not supported for derived discriminated record types.
- The value of a 'Size attribute must be a positive static integer expression. It must be greater than or equal to the minimum size necessary to store the largest possible value of the type. 'Size attributes are supported for all scalar and composite types with the following restrictions:
- 'Storage_Size attributes are supported for access and task types. The value given by a 'Storage_Size attribute can be any integer expression, and it is not required to be static.
- 'Small attributes are supported for fixed-point types. The value given by a 'Small attribute must be a positive static real number that cannot be greater than the delta of the base type. It need not be a power of 2.
Enumeration representation clauses are supported with the following restriction:
- The allowable values for an enumeration clause range from Integer'First to Integer'Last.
Both full and partial representation clauses are supported for both discriminated and undiscriminated records. Record component clauses are not allowed on:
- Array or record fields whose constraint involves a discriminant of the enclosing record
- Array or record fields whose constraint is not static
The static simple expression in the alignment clause part of a record representation clause must be a power of 2 with the following limits:
1 <= static_simple_expression <= 16
The size specified for a discrete field in a component clause must not exceed 32 bits.
Bit numbering in record representation clauses is machine dependent. On big-endian machines, bit 0 maps to the most significant bit. On little-endian machines, bit 0 maps to the least significant bit.
Representation clauses are not supported for derived discriminated record types.
Change of representation is supported wherever it is implied by support for representation specifications. In particular, type conversions between array types might cause packing or unpacking to occur. Conversions between related enumeration types with different representations can result in table-lookup operations.
Representation Attributes
- The meaning of Size for indefinite subtypes. See 13.3(48).
The `Size attribute is not supported on class-wide (tagged) subtypes. The value of the `Size attribute of a specific, indefinite subtype is the maximum size of the type. Evaluating the `Size attribute of a specific, indefinite subtype may raise Constraint_Error.
- The default external representation for a type tag. See 13.3(75).
The default external tag representation is the name of the linker symbol designating the dispatch table of the tagged type.
- What determines whether a compilation unit is the same in two different partitions. See 13.3(76).
The value of the S'External_Tag attribute for a subtype S depends on the name of the compilation unit in which S is declared, the position of the declaration in the compilation unit, and possibly semantic information on the declarations in other compilation units on which S depends. In the absence of editing changes, recompilation will not effect the value of S'External_Tag.
Record Layout
- Implementation-defined components. See 13.5.1(15).
Names are not generated for any implementation defined components. Consequently, a program cannot explicitly refer to implementation defined components, either in a record representation clause or otherwise.
- If Word_Size = Storage_Unit, the default bit ordering. See 13.5.3(5).
The value of Word_Size is 32, the value of Storage_Unit is 8. Hence the default bit ordering is the same as the target-specific ordering of the storage elements in a word.
The Package System
- The contents of the visible part of package System and its language-defined children. See 13.7(2).
Full listings of package System and its language-defined children can be found in the following location.
Native Apex Releases:
$APEX_BASE/ada/lrm.ss/${APEX_ARCH_OS}.ada95.$APEX_PROD_VERSION.relThese meta names are set when Apex is invoked. Their values can be displayed using Tools > Session > Environment command.
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.
The following packages are included in this location:
System
Address_to_Access_Conversions
Machine_Code
Storage_Elements
Storage_PoolsMachine Code Insertions
- The contents of the visible part of package System.Machine_Code, and the meaning of code_statements. See 13.8(7).
Package Machine_Code is implemented for all platforms. Machine code insertions are discussed in detail in Machine Code Insertions.
Unchecked Type Conversions
- The effect of unchecked conversion. See 13.9(11).
The target type of an unchecked conversion must be specific, definite and not a task type.
Unchecked conversion otherwise has the following effect:
- Converting from Discrete, Fixed, Access, or Task Types to Discrete, Fixed, or Access Types
If Source'Size >= Target'Size, the least significant Target'Size bits of the source operand are returned. If Source'Size < Target'Size, the source operand is extended to (at least) Target'Size bits; sign-extended if Source is a signed type and zero-extended otherwise.
- Converting from Discrete, Fixed, Access, or Task Types to Float Types
If the source type has fewer bits than the target type, the algorithm is intended to maximize the probability of producing a NaN (Not a Number). If Source'Size >= Target'Size, the least significant Target'Size bits of the source operand are returned. If Source'Size < Target'Size, the source operand is extended with ones, which usually results in a NaN value.
- Converting from Float Types to Discrete, Fixed, or Access Types
If Source'Size >= Target'Size, the low order bits of the source operand are returned. If Source'Size < Target'Size, the source operand is returned in the least significant bits of the result and zero-extended.
- Converting from Float Types to Float Types
If Source'Size = Target'Size, the source operand is returned as a value of the target type. This is equivalent to a numerical conversion without range checks. If Source'Size /= Target'Size, the result of the operation is undefined.
- Converting from Record or Array Types to Record or Array Types
If Source'Size >= Target'Size, the first Target'Size bits at the address of the source operand are returned. If Source'Size < Target'Size, the source operand is returned in the first Source'Size bits of the result, the remaining bits of the result being undefined. Whether the "first" bits are the least significant bits or the most significant bits depends on the endianness of the target. On
big-endian targets, the "first" bits are the most significant ones.- Converting from Record or Array Types to Discrete, Fixed, or Access Types
If Source'Size >= Target'Size, the first Target'Size bits at the address of the source operand are returned. If Source'Size < Target'Size, the source operand is returned in the least significant bits of the result, which is otherwise filled with zeros.
- Converting from Record or Array Types to Float Types
If Source'Size >= Target'Size, the first Target'Size bits at the address of the source operand are returned. If Source'Size < Target'Size, the source operand is returned in the least significant bits of the result, which is otherwise filled with ones (this should produce a NaN).
- Converting from Scalar, Access, or Task Types to Record or Array Types
If Source'Size >= Target'Size, the least significant Target'Size bits of the source operand are returned. If Source'Size < Target'Size, the source operand is returned in the first Source'Size bits of the result, the remaining bits of the result being undefined.
Storage Management
- The manner of choosing a storage pool for an access type when Storage_Pool is not specified for the type. See 13.11(17).
The compiler typically creates a separate storage pool for each non-derived access type declaration. If several access types are declared at the same scope with similar properties, e.g., the designated types are the same size, then the compiler may choose the same storage pool for to be shared by these similar access types. In any case, a pragma Collection_Policy or a Storage_Size representation clause forces the compiler to select a separate storage pool for the access type.
- Whether or not the implementation provides user-accessible names for the standard pool type(s). See 13.11(17).
The implementation does not provide user-accessible names for the standard storage pools or types.
- The meaning of Storage_Size. See 13.11(18).
When a Storage_Size representation clause is specified for an access type, the `Storage_Size attribute returns the amount of space reserved for the pool (the value specified in the representation clause). Otherwise, the pool is extensible and the attribute returns the amount of space currently reserved for the pool, which may grow as new allocation requests are made for the pool.
- Implementation-defined aspects of storage pools. See 13.11(22).
The allocate procedure is expected to be able to handle alignments ranging from byte-aligned to double-word aligned.
The standard storage pools allocate storage on UNIX platforms by invoking malloc for each allocator. Storage is reclaimed by calling the standard UNIX free routine on calls to instantiations of unchecked_deallocation.
Standard storage pools allocate some additional space for bookkeeping and in some cases, keeping track of the allocated objects so that they can be finalized and/or deallocated upon exit of the scope of the access type.
Pragma Restrictions
- The set of restrictions allowed in a pragma Restrictions. See 13.12(7).
There are no implementation-defined Restrictions
- The consequences of violating limitations on Restrictions pragmas. See 13.12(9).
The following Language Defined Restrictions are caught at compile time:
No_Abort_Statements
No_Terminate_Alternatives
No_Task_Allocators
No_Dynamic_Priorities
No_Asynchronous_Control
No_Protected_Types
No_Allocators
No_Local_Allocators
No_Exceptions
No_Unchecked_Deallocation
No_Unchecked_Conversion
No_Access_Subprograms
No_Unchecked_Access
No_Dispatch
No_Io
No_DelayViolation of the remaining Language Defined Restrictions results in an erroneous program.
Streams
- The representation used by the Read and Write attributes of elementary types in terms of stream elements. See 13.13.2(9).
Values are written out in the normal in-memory representation of their base type. This is the recommendation of 13.13.2(17).
Predefined Language EnvironmentPackage Standard
- The names and characteristics of the numeric subtypes declared in the visible part of package Standard. See A.1(3).
NATURAL and POSITIVE are the only numeric subtypes declared in the visible part of package Standard.
The Numerics Packages
- The accuracy actually achieved by the elementary functions. See A.5.1(1).
The accuracy achieved by the elementary functions is given in the table below. It is expressed in units of EF.Float_Type'Model_Epsilon.
- The sign of a zero result from some of the operators or functions in Numerics.Generic_Elementary_Functions, when Float_Type'Signed_Zeros is True. See A.5.1(46).
The attribute Signed_Zeros is False for all floating point types.
- The value of Numerics.Float_Random.Max_Image_Width. See A.5.2(27).
The named number Ada.Numerics.Float_Random.Max_Image_Width has the value 222.
- The value of Numerics.Discrete_Random.Max_Image_Width. See A.5.2(27).
The named number Ada.Numerics.Discrete_Random.Max_Image_Width has the value 167.
- The algorithms for random number generation. See A.5.2(32).
The random number packages use a Mitchell-Moore additive generator based on the primitive polynomial:
55 24 x + x + 1
The state of the additive generator is initialized using a linear conguential generator with good spectral properties. The period of the additive generator is at least 2 ** 55 - 1 (and probably much larger).
- The string representation of a random number generator's state. See A.5.2(38).
The string representation of generators is a base-64 encoding of the state of the Mitchell-Moore additive generator. The base-64 encoding uses the characters `0 '.. `9', `A' .. `Z', `a' .. `z', `+' and `-'. The first and second character of an image represent two indices in an array of 55 integer values. The rest of the image represent these 55 values. For Discrete_Random, 16-bit integers are used internally, so each element of the array is represented with 3 characters. For Float_Random, 24-bit integers are used internally, so each element of the array is represented using 4 characters.
- The minimum time interval between calls to the time-dependent Reset procedure that are guaranteed to initiate different random number sequences. See A.5.2(45).
Two calls to the time-dependent Reset procedure separated by at least 0.5 seconds are guaranteed to initiate different random number sequences.
- The values of the Model_Mantissa, Model_Emin, Model_Epsilon, Model, Safe_First, and Safe_Last attributes, if the Numerics Annex is not supported. See A.5.3(72).
External Files and File Objects
- Any implementation-defined characteristics of the input-output packages. See A.7(14).
The input-output packages contain no implementation-defined characteristics.
The Generic Package Storage_IO
- The value of Buffer_Size in Storage_IO. See A.9(10).
The value of Ada.Storage_Io.Buffer_Size is: System.Storage_Elements.Storage_Count ((Element_Type'Size + System.Storage_Unit - 1) / System.Storage_Unit);
Text Input-Output
- External files for standard input, standard output, and standard error. See A.10(5).
The external files for standard input, standard output, and standard error correspond to the UNIX input, output and error files of the process, i.e., files 0, 1, and 2 respectively.
- The accuracy of the value produced by Put. See A.10.9(36).
The value produced by Put has at least T'Digits + 1 exact digits. Most of the time the error is of the order of the digit of rank T'Digits + 3.
The Package Command_Line
- The meaning of Argument_Count, Argument, and Command_Name. See A.15(1).
Command_Name corresponds to argv(0), and is conventionally the name of the command used to activate the program. Argument_Count returns the count of the remaining arguments, if any, and Argument returns the arguments starting with the second (that is, Argument(1) corresponds to argv(1)).
Note that if there are no arguments, not even a command name, Command_Name will return the empty string and Argument_Count will return 0.
Interface to Other LanguagesInterfacing Pragmas
- Implementation-defined convention names. See B.1(11).
There are no implementation-defined convention names.
- The meaning of link names. See B.1(36).
The string given as a Link_Name argument in an Import or Export pragma is left unmodified. The string given as the External_Name argument in an Import or Export pragma is modified (typically by prepending a fixed prefix) according to the conventions of the platform's vendor's C compiler.
- The manner of choosing link names when neither the link name nor the address of an imported or exported entity is specified. See B.1(36).
Link names which are not explicitly specified are chosen using a proprietary algorithm which is part of Rational's "smart recompilation" technology.
- The effect of pragma Linker_Options. See B.1(37).
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, its contents will be separated by blanks on the system linker command line. The order in which the arguments appear is undefined.
The Pragma Interface
- The contents of the visible part of package Interfaces and its language-defined descendants. See B.2(1).
Full listings of package Interfaces and its language-defined descendants can be found in the following location.
$APEX_BASE/ada/lrm.ss/${APEX_ARCH_OS}.ada95.$APEX_PROD_VERSION.relAll these meta names are set when Apex is invoked. Their values can be displayed using Tools > Session > Environment command.
The location of these packages for the Apex cross products is dependent on the target processor and runtime variant. Use Table 50 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.
The following packages are provided in this location:
Interfaces
Interfaces.C
Interfaces.C.Pointers
Interfaces.C.Strings- Implementation-defined children of package Interfaces. The contents of the visible part of package Interfaces. See B.2(11).
There are no implementation-defined children of package Interfaces.
Interfacing with COBOL
- The types Floating, Long_Floating, Binary, Long_Binary, Decimal_Element, and COBOL_Character; and the initializations of the variables Ada_To_COBOL and COBOL_To_Ada, in Interfaces.COBOL See B.4(50).
The Information Systems special needs annex (Annex F) is not supported by this implementation. Interfacing to COBOL is not supported.
Systems ProgrammingAccess to Machine Operations
- Support for access to machine instructions. See C.1(1).
Access to machine instructions is discussed in detail in Machine Code Insertions.
- Implementation-defined aspects of access to machine operations. See C.1(9).
Implementation-defined aspects of access to machine operations are discussed in detail in Machine Code Insertions.
Interrupt Support
- Implementation-defined aspects of interrupts. See C.3(2).
Interrupts are implemented as UNIX signals on the Apex Self platforms. When signals are blocked, only one incoming signal will be held pending; further signals will be lost.
Reserved interrupts (signals) for Solaris, Alpha are all synchronous signals:
SIGILL
SIGTRAP
SIGEMT
SIGFPE
SIGBUS
SIGSEGV
SIGSYSThese have the highest priority, System.Interrupt_Priority'Last .. System.Interrupt_Priority'Last - 7, respectively. The remaining signals are assigned arbitrary priorities of System.Interrupt_Priority'First + <signal number>.
Preelaboration Requirements
- Implementation-defined aspects of preelaboration. See C.4(13).
The elaboration of a preelaborated package does not cause code to be executed at run time.
Pragma Discard_Names
- The semantics of pragma Discard_Names. See C.5(7).
Task Identification and Attributes
- The result of the Task_Identification.Image attribute. See C.7.1(7).
Task_Identification.Image returns a decimal string representation of a sequence number unique to it's Task_Id argument.
- The value of Current_Task when in a protected entry or interrupt handler. See C.7.1(17).
When called from within a protected entry body, Task_Identification.Current_Task returns the Task_Id of the task executing the body. This may or may not be the caller, but will be a task executing a protected procedure or entry on the corresponding protected object. When called from within an interrupt handler, Task_Identification.Current_Task returns Task_Identification.Null_Task_Id.
- The effect of calling Current_Task from an entry body or interrupt handler. See C.7.1(19).
When called from with a protected entry body or interrupt handler, Task_Identification.Current_Task returns an implementation-defined value of Task_Id. See item 87, above.
- Implementation-defined aspects of Task_Attributes. See C.7.2(19).
The total size of all task attribute objects is limited to a per-task storage area. This area is 64 storage units by default, and can be specified by the user using
pragma Main (Task_Storage_Size => <total space in storage units>);
Real-Time Systems
- Values of all Metrics. See D(2).
Upper bounds cannot be established for these metrics on UNIX multiprocessing systems, since other UNIX processes may preempt an Ada program.
Task Priorities
- The declarations of Any_Priority and Priority. See D.1(11).
The declarations are as follows:
subtype Any_Priority is Integer range 0 .. 100; subtype Priority is Any_Priority range Any_Priority'First .. 99;- Implementation-defined execution resources. See D.1(15).
Priority Scheduling
- Whether, on a multiprocessor, a task that is waiting for access to a protected object keeps its processor busy. See D.2.1(3).
A task waiting for an execution resource does not keep its processor busy.
- The affect of implementation defined execution resources on task dispatching. See D.2.1(9).
There are no implementation-defined execution resources.
- Implementation-defined policy_identifiers allowed in a pragma Task_Dispatching_Policy. See D.2.2(3).
There are no implementation-defined policy_identifiers allowed in a Task_Dispatching_Policy pragma.
- Implementation-defined aspects of priority inversion. See D.2.2(16).
The Ada runtime system uses mutual exclusion locks (mutexes) to synchronize Ada operations between tasks. The default is to use a mutex which has no effect on priority, which can cause a low-priority task to block indefinitely. The user can configure the system to use ceiling mutexes which raise the priority of a task in the runtime such that no intermediate priority task can preempt a low-priority task holding a mutex and thereby run at the expense of a high-priority task, thus limiting priority inversion to the time spent in the runtime. However, on the UNIX-based systems described by this document, a processor context switch can occur while a low-priority task is in the runtime blocking a high-priority task, and so no upper limit can be assigned to the duration of priority inversion.
- Implementation defined task dispatching. See D.2.2(18).
There are no implementation-defined task dispatching points in the standard configuration. The user can configure the system to provide a form of time slicing; such a configuration does not comply with the standard.
Priority Ceiling Locking
- Implementation-defined policy_identifiers allowed in a pragma Locking_Policy. See D.3(4).
There are no implementation-defined policy_identifiers allowed in a Locking_Policy pragma.
- Default ceiling priorities. See D.3(10).
The default ceiling priority for a protected object which contains interrupt handlers is Interrupt_Priority'Last; for other protected objects, the default ceiling priority is Priority'Last.
- The ceiling of any protected object used internally by the implementation. See D.3(16).
Entry Queuing Policies
- Implementation-defined queuing policies. See D.4(1).
Preemptive Abort
- On a multiprocessor, any conditions that cause the completion of an aborted construct to be delayed later than what is specified for a single processor. See D.6(3).
Tasking Restrictions
- Any operations that implicitly require heap storage allocation. See D.7(8).
The following operations implicitly require heap-storage allocation:
- Allocators
- Creation of dynamic-sized objects and values in a static scope
- Creation of dynamic-sized objects and values in a separate non-generic package body
- Implementation-defined aspects of pragma Restrictions. See D.7(20).
There are no reductions in executable program size, storage requirements or execution time that result from using pragma Restrictions.
Monotonic Time
- Implementation-defined aspects of package Real_Time. See D.8(17).
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
- Implementation-defined aspects of delay_statements. See D.9(8).
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
- The upper bound on the duration of interrupt blocking caused by the implementation. See D.12(5).
The UNIX systems covered by this document use the Ada interrupt model to handle UNIX signals. Since a program executed under any of these systems preempted by another UNIX process for an arbitrary amount of time while running a task which has signals blocked, there is no upper limit to the amount of time that a task can have signals blocked.
Distributed Systems
- The means for creating and executing distributed programs. See E(5).
The Distributed Systems special needs annex (Annex E) is not supported.
Partitions
- Any events that can result in a partition becoming inaccessible. See E.1(7).
The Distributed Systems special needs annex (Annex E) is not supported.
- The scheduling policies, treatment of priorities, and management of shared resources between partitions in certain cases. See E.1(11).
The Distributed Systems special needs annex (Annex E) is not supported.
Consistency of a Distributed System
- Events that cause the version of a compilation unit to change. See E.3(5).
The Distributed Systems special needs annex (Annex E) is not supported.
Remote Subprogram Calls
- Whether the execution of the remote subprogram is immediately aborted as a result of cancellation. See E.4(13).
The Distributed Systems special needs annex (Annex E) is not supported.
Partition Communication Subsystem
- Implementation-defined aspects of the PCS. See E.5(25).
The Distributed Systems special needs annex (Annex E) is not supported.
- Implementation-defined interfaces in the PCS. See E.5(26).
The Distributed Systems special needs annex (Annex E) is not supported.
Information SystemsThe Package Decimal
- The values of named numbers in the package Decimal. See F.2(7).
The Information Systems special needs annex (Annex F) is not supported.
Edited Output for Decimal Types
- The value of Max_Picture_Length in the package Text_IO.Editing. See F.3.3(16).
The Information Systems special needs annex (Annex F) is not supported.
- The value of Max_Picture_Length in the package Wide_Text_IO.Editing. See F.3.4(5).
The Information Systems special needs annex (Annex F) is not supported.
NumericsComplex Arithmetic
- The accuracy actually achieved by the complex elementary functions and by other complex arithmetic operations. See G.1(1).
The accuracy achieved by the complex elementary functions and by other complex arithmetic operations is given in the table below. It is expressed in units of Ct.Real'Model_Epsilon. For functions returning a complex number, the nature of the error (box or relative) is indicated.
- The sign of a zero result (or a component thereof) from any operator or function in Numerics.Generic_Complex_Types, when Real'Signed_Zeros is True. See G.1.1(53).
The attribute Signed_Zeros is False for all floating-point types.
- The sign of a zero result (or a component thereof) from any operator or function in Numerics.Generic_Complex_Elementary_Functions, when Complex_Types.Real'Signed_Zeros is True. See G.1.2(45).
The attribute Signed_Zeros is False for all floating-point types.
Numeric Performance Requirements
- Whether the strict mode or the relaxed mode is the default. See G.2(2).
There is no relaxed mode. The strict mode is the default.
- The result interval in certain cases of fixed-to-float conversion. See G.2.1(10).
In the case described in G.2.1(10), the fixed-point-to-floating-point conversion is implemented in two steps. First, the (unscaled) integer representation of the fixed point value is converted to the floating point representation; this is done in the same way as for any integer-to-floating-point conversion. Second, the resulting floating point value is scaled by multiplying by the floating point representation of the (static) SMALL of the fixed point type. When appropriate, this multiplication is implemented by dividing by the inverse.
- The result of a floating point arithmetic operation in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.1(13).
Constraint_Error is raised in overflow situations.
- The result interval for division (or exponentiation by a negative exponent), when the floating point hardware implements division as multiplication by a reciprocal. See G.2.1(16).
The instruction set of the underlying hardware (for all 6 targets) includes a floating_point divide instruction. Division is not implemented (at the instruction set level) as multiplication by a reciprocal.
- The definition of close result set, which determines the accuracy of certain fixed point multiplications and divisions. See G.2.3(5).
Two floating point representations are supported: IEEE basic single and double precision types (see AARM95 G.2.2(11.a)). The close set of a given floating point type is as defined by its IEEE representation
- Conditions on a universal_real operand of a fixed point multiplication or division for which the result shall be in the perfect result set. See G.2.3(22).
The result of a Universal_Fixed-valued fixed point multiplication or division is in the perfect result set in all cases.
- The result of a fixed point arithmetic operation in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.3(27).
The MACHINE_OVERFLOWS attribute is True for all fixed point types.
- The result of an elementary function reference in overflow situations, when the Machine_Overflows attribute of the result type is False. See G.2.4(4).
The MACHINE_OVERFLOWS attribute is True for all floating point types.
- The value of the angle threshold, within which certain elementary functions, complex arithmetic operations, and complex elementary functions yield results conforming to a maximum relative error bound. See G.2.4(10).
The angle threshold for the reduction of the argument of trigonometric functions is 2 ** 12 for Float (and types derived thereof) and 2 ** 26 for Long_Float (and types derived thereof).
- The accuracy of certain elementary functions for parameters beyond the angle threshold. See G.2.4(10).
Immediately above the angle threshold, the relative error on the trigonometric functions is approximately 2.0E4 for Float and 2.0E9 for Long_Floats (expressed in units of EF.Float_Type'Model_Epsilon). The relative error increases for larger angles.
- The result of a complex arithmetic operation or complex elementary function reference in overflow situations, when the Machine_Overflows attribute of the corresponding real type is False. See G.2.6(5).
The attribute Machine_Overflows is True for all floating-point types.
- The accuracy of certain complex arithmetic operations and certain complex elementary functions for parameters (or components thereof) beyond the angle threshold. See G.2.6(8).
The complex operations and elementary functions are implemented in terms of the floating-point elementary functions. In particular, the following subprograms from Generic_Complex_Types and Generic_Elementary_Functions rely on trigonometric functions for their implementation, and are subject to relative errors similar to those mentioned above, when their argument exceeds the angle threshold: Compose_From_Polar, Exp, "**", complex trigonometric functions, complex hyperbolic functions.
Safety and SecurityTable 51 describes the handling of each restriction as required in Annex H, section H.2.
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. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |