Annex D
(normative)
Real-Time Systems
1
{real-time systems}
{embedded systems}
This Annex specifies additional characteristics of
Ada implementations intended for real-time systems software. To conform
to this Annex, an implementation shall also conform to the Systems Programming
Annex.
Metrics
2
The metrics are documentation requirements; an implementation
shall document the values of the language-defined metrics for at least
one configuration [of hardware or an underlying system] supported by
the implementation, and shall document the details of that configuration.
2.a/2
This paragraph
was deleted.Implementation defined:
Values of all Metrics.
2.a.1/2
Documentation Requirement:
The details of the configuration used
to generate the values of all metrics.
2.b
Reason: The actual values of the metrics
are likely to depend on hardware configuration details that are variable
and generally outside the control of a compiler vendor.
3
The metrics do not necessarily yield a simple number.
[For some, a range is more suitable, for others a formula dependent on
some parameter is appropriate, and for others, it may be more suitable
to break the metric into several cases.] Unless specified otherwise,
the metrics in this annex are expressed in processor clock cycles. For
metrics that require documentation of an upper bound, if there is no
upper bound, the implementation shall report that the metric is unbounded.
3.a
Discussion: There are several good reasons
to specify metrics in seconds; there are however equally good reasons
to specify them in processor clock cycles. In defining the metrics, we
have tried to strike a balance on a case-by-case basis.
3.b
It has been suggested that all metrics should
be given names, so that “data-sheets” could be formulated
and published by vendors. However the paragraph number can serve that
purpose.
4
1 The specification of the metrics makes
a distinction between upper bounds and simple execution times. Where
something is just specified as “the execution time of” a
piece of code, this leaves one the freedom to choose a nonpathological
case. This kind of metric is of the form “there exists a program
such that the value of the metric is V”. Conversely, the meaning
of upper bounds is “there is no program such that the value of
the metric is greater than V”. This kind of metric can only be
partially tested, by finding the value of V for one or more test programs.
5
2 The metrics do not cover the whole language;
they are limited to features that are specified in
Annex
C, “
Systems Programming” and
in this Annex. The metrics are intended to provide guidance to potential
users as to whether a particular implementation of such a feature is
going to be adequate for a particular real-time application. As such,
the metrics are aimed at known implementation choices that can result
in significant performance differences.
6
3 The purpose of the metrics is not necessarily
to provide fine-grained quantitative results or to serve as a comparison
between different implementations on the same or different platforms.
Instead, their goal is rather qualitative; to define a standard set of
approximate values that can be measured and used to estimate the general
suitability of an implementation, or to evaluate the comparative utility
of certain features of an implementation for a particular real-time application.
Extensions to Ada 83
6.a
{
extensions to Ada 83}
This
Annex is new to Ada 95.
Sponsored by Ada-Europe