- This clause specifies additional implementation and documentation
requirements for the Preelaborate pragma (see 10.2.1).
- The implementation shall not incur any run-time overhead for the
elaboration checks of subprograms and protected_bodies declared in
preelaborated library units.
- The implementation shall not execute any memory write operations after
load time for the elaboration of constant objects declared immediately within
the declarative region of a preelaborated library package, so long as the
subtype and initial expression (or default initial expressions if initialized
by default) of the object_declaration satisfy the following restrictions.
The meaning of load time is implementation defined.
- Any subtype_mark denotes a statically constrained subtype, with
statically constrained subcomponents, if any;
- any constraint is a static constraint;
- any allocator is for an access-to-constant type;
- any uses of predefined operators appear only within static
- any primaries that are names, other than attribute_references for
the Access or Address attributes, appear only within static
- any name that is not part of a static expression is an expanded
name or direct_name that statically denotes some entity;
- any discrete_choice of an array_aggregate is static;
- no language-defined check associated with the elaboration of the
object_declaration can fail.
- The implementation shall document any circumstances under which the
elaboration of a preelaborated package causes code to be executed at run
- The implementation shall document whether the method used for
initialization of preelaborated variables allows a partition to be restarted
- It is recommended that preelaborated packages be implemented in such a
way that there should be little or no code executed at run time for the
elaboration of entities not already covered by the Implementation
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Page last generated: 95-03-12