Skip to main content

C.4 Preelaboration Requirements

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1/5

[This subclause specifies additional implementation and documentation requirements for the Preelaborate aspect (see 10.2.1).]

Implementation Requirements

2

The implementation shall not incur any run-time overhead for the elaboration checks of subprograms and protected_bodies declared in preelaborated library units.

3

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.

3.a
discussion

On systems where the image of the partition is initially copied from disk to RAM, or from ROM to RAM, prior to starting execution of the partition, the intention is that “load time” consist of this initial copying step. On other systems, load time and run time might actually be interspersed.

4
  • Any subtype_mark denotes a statically constrained subtype, with statically constrained subcomponents, if any;
  • 4.1/2
  • no subtype_mark denotes a controlled type, a private type, a private extension, a generic formal private type, a generic formal derived type, or a descendant of such a type;
4.a.1/2
implementation advice

For an implementation that uses the registration method of finalization, a controlled object will require some code executed to register the object at the appropriate point. The other types are those that might have a controlled component. None of these types were allowed in preelaborated units in Ada 95. These types are covered by the , of course, so they should still execute as little code as possible.

5
  • any constraint is a static constraint;
  • 6
  • any allocator is for an access-to-constant type;
  • 7
  • any uses of predefined operators appear only within static expressions;
  • 8
  • any primaries that are names, other than attribute_references for the Access or Address attributes, appear only within static expressions;
8.a
ramification

This cuts out attribute_references that are not static, except for Access and Address.

9/5
  • any name that is not part of a static expression is an expanded name or direct_name that statically names some entity;
9.a/5
ramification

This cuts out function_calls and type_conversions that are not static, including calls on attribute functions like 'Image and 'Value. We do allow components if those components don't require any evaluation or checks.

10
11.a/2
reason

The intent is that aggregates all of whose scalar subcomponents are static and all of whose access subcomponents are null, allocators for access-to-constant types, or X'Access, will be supported with no run-time code generated.

Documentation Requirements

12

The implementation shall document any circumstances under which the elaboration of a preelaborated package causes code to be executed at run time.

12.a/2

Documentation Requirement: Any circumstances when the elaboration of a preelaborated package causes code to be executed.

13

The implementation shall document whether the method used for initialization of preelaborated variables allows a partition to be restarted without reloading.

13.a.1/2

Documentation Requirement: Whether a partition can be restarted without reloading.

13.a/2
This paragraph was deleted.
13.b/2
discussion

This covers the issue of the run-time system itself being restartable, so that need not be a separate Documentation Requirement.

Implementation Advice

14

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

14.a/2
implementation advice

Preelaborated packages should be implemented such that little or no code is executed at run time for the elaboration of entities.

Wording Changes from Ada 95

14.b/2

Added wording to exclude the additional kinds of types allowed in preelaborated units from the Implementation Requirements.

Wording Changes from Ada 2012

14.c/5

Added wording to allow components so long as no evaluation or checks are required for the reference.