- (1)
- An Ada program consists of a set of partitions, which can execute in
parallel with one another, possibly in a separate address space, and possibly
on a separate computer.
Post-Compilation Rules
- (2)
- A partition is a program or part of a program that can be invoked from
outside the Ada implementation. For example, on many systems, a partition
might be an executable file generated by the system linker. The user can
explicitly assign library units to a partition. The assignment is done in an
implementation-defined manner. The compilation units included in a partition
are those of the explicitly assigned library units, as well as other
compilation units needed by those library units. The compilation units
needed by a given compilation unit are determined as follows (unless
specified otherwise via an implementation-defined pragma, or by some other
implementation-defined means):
- (3)
- A compilation unit needs itself;
- (4)
- If a compilation unit is needed, then so are any compilation
units upon which it depends semantically;
- (5)
- If a library_unit_declaration is needed, then so is any
corresponding library_unit_body;
- (6)
- If a compilation unit with stubs is needed, then so are any
corresponding subunits.
- (7)
- The user can optionally designate (in an implementation-defined manner)
one subprogram as the main subprogram for the partition. A main subprogram,
if specified, shall be a subprogram.
- (8)
- Each partition has an anonymous environment task, which is an implicit
outermost task whose execution elaborates the library_items of the
environment declarative_part, and then calls the main subprogram, if there is
one. A partition's execution is that of its tasks.
- (9)
- The order of elaboration of library units is determined primarily by the
elaboration dependences. There is an elaboration dependence of a given
library_item upon another if the given library_item or any of its subunits
depends semantically on the other library_item. In addition, if a given
library_item or any of its subunits has a pragma Elaborate or Elaborate_All
that mentions another library unit, then there is an elaboration dependence
of the given library_item upon the body of the other library unit, and, for
Elaborate_All only, upon each library_item needed by the declaration of the
other library unit.
- (10)
- The environment task for a partition has the following structure:
(11)
task Environment_Task;
(12)
task body Environment_Task is
... (1) -- The environment declarative_part
-- (that is, the sequence of library_items) goes here.
begin
... (2) -- Call the main subprogram, if there is one.
end Environment_Task;
- (13)
- The environment declarative_part at (1) is a sequence of declarative_items consisting of copies of the library_items included in the partition.
The order of elaboration of library_items is the order in which they appear
in the environment declarative_part:
- (14)
- The order of all included library_items is such that there are no
forward elaboration dependences.
- (15)
- Any included library_unit_declaration to which a pragma
Elaborate_Body applies is immediately followed by its library_unit_body, if included.
- (16)
- All library_items declared pure occur before any that are not
declared pure.
- (17)
- All preelaborated library_items occur before any that are not
preelaborated.
- (18)
- There shall be a total order of the library_items that obeys the above
rules. The order is otherwise implementation defined.
- (19)
- The full expanded names of the library units and subunits included in a
given partition shall be distinct.
- (20)
- The sequence_of_statements of the environment task (see (2) above)
consists of either:
- (21)
- A call to the main subprogram, if the partition has one. If the
main subprogram has parameters, they are passed; where the
actuals come from is implementation defined. What happens to the
result of a main function is also implementation defined.
- (22)
- or:
- (23)
- A null_statement, if there is no main subprogram.
- (24)
- The mechanisms for building and running partitions are implementation
defined. These might be combined into one operation, as, for example, in
dynamic linking, or ``load-and-go'' systems.
Dynamic Semantics
- (25)
- The execution of a program consists of the execution of a set of
partitions. Further details are implementation defined. The execution of a
partition starts with the execution of its environment task, ends when the
environment task terminates, and includes the executions of all tasks of the
partition. The execution of the (implicit) task_body of the environment task
acts as a master for all other tasks created as part of the execution of the
partition. When the environment task completes (normally or abnormally), it
waits for the termination of all such tasks, and then finalizes any remaining
objects of the partition.
Bounded (Run-Time) Errors
- (26)
- Once the environment task has awaited the termination of all other tasks
of the partition, any further attempt to create a task (during finalization)
is a bounded error, and may result in the raising of Program_Error either
upon creation or activation of the task. If such a task is activated, it is
not specified whether the task is awaited prior to termination of the
environment task.
Implementation Requirements
- (27)
- The implementation shall ensure that all compilation units included in a
partition are consistent with one another, and are legal according to the
rules of the language.
Implementation Permissions
- (28)
- The kind of partition described in this clause is known as an active
partition. An implementation is allowed to support other kinds of
partitions, with implementation-defined semantics.
- (29)
- An implementation may restrict the kinds of subprograms it supports as
main subprograms. However, an implementation is required to support all main
subprograms that are public parameterless library procedures.
- (30)
- If the environment task completes abnormally, the implementation may
abort any dependent tasks.
-
- (31)
(8) An implementation may provide inter-partition communication mechanism(s)
via special packages and pragmas. Standard pragmas for distribution and
methods for specifying inter-partition communication are defined in Annex
E, ``Distributed Systems''. If no such mechanisms are provided, then
each partition is isolated from all others, and behaves as a program in
and of itself.
- (32)
(9) Partitions are not required to run in separate address spaces. For
example, an implementation might support dynamic linking via the
partition concept.
- (33)
(10) An order of elaboration of library_items that is consistent with the
partial ordering defined above does not always ensure that each library_unit_body
is elaborated before any other compilation unit whose elaboration necessitates
that the library_unit_body be already elaborated. (In particular, there
is no requirement that the body of a library unit be elaborated as soon
as possible after the library_unit_declaration is elaborated, unless the
pragmas in subclause 10.2.1 are used.)
- (34)
(11) A partition (active or otherwise) need not have a main subprogram.
In such a case, all the work done by the partition would be done by elaboration
of various library_items, and by tasks created by that elaboration. Passive
partitions, which cannot have main subprograms, are defined in Annex
E, ``Distributed Systems''.
Subclauses
- Elaboration Control
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12