![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Configuration Pragmas Configuration pragmas are an Ada 95 feature described (briefly) in [RM_95 10.1.5(8)]. Apex contains a sophisticated implementation of configuration pragmas for both Ada 83 and Ada 95 that leverages the optimal recompilation capabilities of the environment.
Configuration PragmasEach Ada view can contain a special Ada unit whose name is pragma.1.ada. This "pragma unit" must contain only configuration pragmas. It can be created using the File > New > Ada dialog; from the drop-down list in the dialog, select "Pragmas". There can be at most one pragma unit in any Ada view, and its name cannot be changed. This unit cannot be mentioned in a with clause (an attempt to construct such a with clause would fail because the construct "with pragma;" violates Ada syntax rules). You can edit, check syntax, pretty print, semanticize, and compile a pragma unit using the Ada editor. Pragma units do not have associated machine code, and coding them has no effect.
Every Ada unit in a view implicitly depends on the pragma unit; changes to the pragma unit will cause recompilation of other units in the view that are affected by the particular changes made to the pragmas. Whether a configuration pragma has effect on another unit does not depend on the order in which units were compiled or the time at which the pragma unit was changed, but at the same time unnecessary recompilation is avoided by fine-grain tracking of dependencies.
Configuration pragmas can also be applied to an individual unit by placing them at the very beginning of the unit.
The following language-defined configuration pragmas are supported:
- pragma Assertion_Policy
- pragma Concurrent_Processing_Policy
- pragma Discard_Names
- pragma Import_Directive
- pragma Inlining_Policy
- pragma Locking_Policy
- pragma Normalize_Scalars
- pragma Optimize
- pragma Profile
- pragma Queuing_Policy
- pragma Restrictions
- pragma Suppress
- pragma Suppress_Elaboration_Checks
- pragma Task_Dispatching_Policy
- pragma Unsuppress
pragma Assertion_Policy
This pragma specifies whether checking code is generated.
When the value is Check, any pragma Assert is active, possibly raising System.Assertion_Error.
When the value is Ignore, no checking code is generated for a pragma Assert. Apex does not currently support ignoring assertions.
pragma Concurrent_Processing_Policy
This pragma specifies the processing policy. At most one concurrent processing policy may be specified for the entire program. Allowable values are:
The default is Interleaved_Processing. Some targets, notably Linux, only support Threaded_Processing.
- Interleaved_Processing
- Threaded_Processing
pragma Discard_Names
This pragma currently has no effect. The implementation would have the same effect as applying this pragma to each unit. Discard_Names is intended to allow the omission of support code, for instance, the tables necessary to generate the 'Image and 'Value functions for enumeration types.
pragma Import_Directive
This pragma specifies the parameter passing policy default for subprograms referenced by pragma Import to C. Allowable values (C calling conventions) are:
- ANSI
- K&R
pragma Inlining_Policy
This pragma specifies how the compiler treats Inline pragmas.
When the value is Conservative, the compiler attempts to choose good chandidates for inlining based on Inline pragmas, routine size, and other considerations.When the value is Agressive, the compiler attempts to do as much inlining as it feasibly can, which may lead to significant increases in performance and program size.
When the value is Obedient, the compiler will inline units so specified, if it can, and not attempt inlining on any other units.
pragma Locking_Policy
This pragma affects various tasking policies as defined in the Real-Time Systems Annex. When a main program is linked, a check is made that there are no conflicts among the policies prescribed in the views comprised by the main program. If one of these pragmas appears inside an Ada unit, for that unit it overrides the value specified in the pragma unit.
When the value is Ceiling_Locking, ceiling priorities are implemented for protected objects. A task running at a priority below this ceiling will have its priority raised to the ceiling during the execution of a protected action. The other possible value is No_Priority_Inheritance_Locking.
Note: This pragma is not supported in Ada 83.
pragma Normalize_Scalars
This pragma provides a means to force an implementation of Normalize_Scalars to use an out-of-range value. For an integer type, this is done by providing a size specification such that spare bits are present. For a floating point type, spare bits might not be available, but a range constraint can provide the ability to use an out-of-range value. This can be tested for by ensuring that Constraint_Error is raised.
pragma Optimize
This pragma specifies the code optimization preference. Allowable values are:
- Time
- Space
pragma Profile
This pragma allows specifications of the Ravenscar restrictions on language features used. This is supported with the caveat that
do not have any runtime effect.
- No_Task_Termination
- Max_Entry_Queue_Length
- Defect_Blocking
pragma Queuing_Policy
This pragma affects various tasking policies as defined in the Real-Time Systems Annex. When a main program is linked, a check is made that there are no conflicts among the policies prescribed in the views comprised by the main program. If one of these pragmas appears inside an Ada unit, for that unit it overrides the value specified in the pragma unit.
This pragma specifies the order in which tasks are queued for entry service and the order in which different entry queues are considered for service. Allowable values are:
The default value is FIFO_Queuing.
- FIFO_Queuing
- Priority_Queuing
Note: This pragma is not supported in Ada 83.
pragma Restrictions
This pragma allows the programmer to assert that certain features of the Ada language must not be used anywhere in a program. If a language restriction is mentioned in a configuration pragma, then the restriction is said to be enforced in the view or unit where the pragma appears. If the compiler chooses to generate different code for a construct because of an enforced restriction, the restriction is said to be exploited. If a unit does not honor a restriction (whether or not a restriction pragma applies to the unit), the unit violates the restriction.
Apex detects violations of most enforced restrictions at installation time. For example, in a view where pragma Restriction (No_Abort_Statements) appears, units containing the keyword abort will fail to install. Some violations (No_Implicit_Heap_Allocations) cannot be detected until code generation time, some at runtime (Max_Tasks), and others not at all. Apex only provides enforcement at installation time; future releases will provide support for enforcement at code generation time and runtime. The degree of support in Apex for the predefined restrictions is listed in Table 19.
At code generation time, Apex can exploit a restriction where it is enforced. In this release, Apex exploits the combination of two restrictions: If No_Abort_Statements and Max_Asynchronous_Select_Nesting => 0 are both enforced, then Apex will generate improved code in several situations, particularly for objects of controlled types. There is also some benefit of this combination in Ada 83.
In any main program containing units to which a restriction applies, Apex guarantees that none of the units in the program violate the restriction; this check is performed at prelink time. Thus it is not necessary that all the views that contribute to a program have the same restriction pragmas; it is only required that none of the units in the program violate any of the restrictions enforced in any of the units or views in the program.
Treatment of configuration pragmas is consistent in API's. For example, if a view inside an API specifies a restriction, Apex will not link a main program containing units that violate that restriction. None of the Rational-supplied predefined libraries or API's contain any restriction or real-time policy pragmas.
Rational has defined two additional restrictions in Apex; they are No_Tasking and No_Requeue_Statements. When No_Tasking is enforced, the keyword task cannot appear; when No_Requeue_Statements is enforced, the keyword requeue cannot appear.
pragma Suppress
Pragma Suppress can be specified one or more times in the pragma unit. Checks are suppressed during code generation just as if the pragmas appeared in each unit in the view. If checks are added or removed from the set of checks suppressed in the pragma unit, already-coded units will be recoded if and only if they contain constructs that would cause those checks to be performed. For example, suppose "pragma Suppress (Index_Check)" is added to (or removed from) the pragma unit; any coded unit in the view that performs array indexing (whether explicitly or due to inlining or generic instantiation) will be considered obsolete and will be recoded at the appropriate time. Already-coded units that do not perform array indexing will not be recoded because of this change. Pragma Suppress appearing inside an Ada unit behaves as it always has; the suppressions in effect are the union of those local to the unit and those in the pragma unit. Use of pragma Suppress as a configuration pragma is supported in both Ada 83 and Ada 95.
pragma Suppress_Elaboration_Checks
This pragma will supress all elaboration checking for this view.
pragma Task_Dispatching_Policy
This pragma affects various tasking policies as defined in the Real-Time Systems Annex. When a main program is linked, a check is made that there are no conflicts among the policies prescribed in the views comprised by the main program. If one of these pragmas appears inside an Ada unit, for that unit it overrides the value specified in the pragma unit.
Note: This pragma is not supported in Ada 83.
pragma Unsuppress
This pragma is the opposite of pragma Suppress. The effect of Supress and Unsupress pragams referencing the same check depends on the order in which they appear in the list of pragmas.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2004, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |