CVS difference for ai05s/ai05-0170-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0170-1.txt

--- ai05s/ai05-0170-1.txt	2010/02/20 04:13:46	1.2
+++ ai05s/ai05-0170-1.txt	2010/06/13 01:40:08	1.3
@@ -1,5 +1,8 @@
-!standard  D.14(29/2)                                10-02-18    AI05-0170-1/02
-!standard  D.14.1(28/2)
+!standard  D.14(9/2)                                10-06-04    AI05-0170-1/03
+!standard  D.14(11/2)
+!standard  D.14(13/2)
+!standard  D.14(18/2)
+!standard  D.14.3(0)
 !class Amendment 09-10-22
 !status work item 09-10-22
 !status received 09-10-22
@@ -68,6 +71,140 @@
 
 !proposal
 
+See wording and discussion.
+
+!wording
+
+Add to package Ada.Execution_Time in D.14: [Where? After D.14(9/2)?? Editor.]
+
+Interrupt_Clocks_Supported : constant Boolean := <implementation-defined>;
+
+Separate_Interrupt_Clocks_Supported : constant Boolean :=
+  <implementation-defined>;
+
+function Clock_For_Interrupts return CPU_Time;
+
+
+Change 11/2 to:
+The execution time or CPU time of a given task is defined as the time spent
+by the system executing that task, including the time spent executing run-time
+or system services on its behalf. The mechanism used to measure execution time
+is implementation defined. The Boolean constant Interrupt_Clocks_Supported is
+set to True if the implementation separately accounts for the execution time
+of interrupt handlers. If it is set to False it is implementation defined which
+task, if any, is charged the execution time that is consumed by interrupt
+handlers. The Boolean constant Separate_Interrupt_Clocks_Supported is set to
+True if the implementation separately accounts for the execution time of
+individual interrupt handlers. If set to True the package
+Ada.Execution_Time.Interrrupts must be supported (see D.14.3).
+
+Add to end of 13/2:
+The execution time value for the Clock_For_Interrupts is initialised to zero.
+
+
+
+Add to Dynamic Semantics [Where? After D.14(18/2)?? Editor.]
+
+The function Clock_For_Interrupts returns the total cumulative time spent
+executing within all interrupt handlers. This time is not allocated to any
+task execution time clock. If Interrupt_Clocks_Supported is set to False
+the function will return a value equal to Time_Of(0).
+
+
+
+Add a new D.14.3
+
+This clause describes a language-defined package to measure the execution
+time of interrupt handlers.
+
+Static Semantics
+The following language-defined library exists:
+
+with Ada.Interrupts;
+package Ada.Execution_Time.Interrupts is
+   function Clock (I : Ada.Interrupts.Interrupt_ID)
+        return CPU_Time;
+   function Supported (I : Ada.Interrupts.Interrupt_ID)
+        return Boolean;
+end Ada.Execution_Time.Interrupts;
+
+The execution time or CPU time of a given interrupt I is defined as the time
+spent by the system executing interrupt handlers identified by I, including
+the time spent executing run-time or system services on its behalf.
+The mechanism used to measure execution time is implementation defined.
+Time spent executing interrupt handlers is distinct from time spent
+executing any task.
+
+For each interrupt ID, the execution time value is initially set to zero.
+
+
+Dynamic Semantics
+The function Clock returns the current cumulative execution time of the
+interrupt identified by I. If Separate_Interrupt_Clocks_Supported is
+set to False the function will always return a value equal to
+Ada.Execution_Time.Time_Of(0).
+
+
+The function Supported returns True if the implementation is monitoring
+the execution time of interrupt I. Otherwise it returns False. For any
+interrupt ID I for which Supported(I) returns False, the function Clock(I)
+will return a value equal to Ada.Execution_Time.Time_Of(0).
+
+
+!discussion
+
+This AI contains a proposal to add to the Ada standard
+implementation advice on how to handle the measurement of the
+execution time of interrupt handlers separately from the execution
+time of user tasks.
+
+The most interesting aspect of the new service is that it can
+significantly enhance the accuracy of the execution time clocks and
+timers of user tasks, because they are not arbitrarily charged with
+the execution times of interrupt service handlers.
+
+This support for managing the execution time of interrupt handlers
+does not require any language modification or the addition of any new
+API. However, once the interrupt execution time is measured, it can be
+made available to Ada applications via special clocks that
+measure the execution time of the interrupt handlers associated with a
+given interrupt Id.
+
+Moreover, it is possible to extend the current execution time timers
+to use the newly defined execution time clocks for interrupt handlers,
+thus introducing the ability for the system to detect execution time
+violations in interrupt handlers.
+
+Since all this functionality may not be available on all platforms it
+is only proposed as implementation advice, to be implemented when
+appropriate.
+
+In [1] and [2] the overheads incurred by the implementation of these
+new services have been measured, and found that they are very low in
+comparison with the execution times of common interrupt
+handlers.
+
+Regarding the proposed API, it would be possible to define a Task_Id
+for pseudo tasks representing interrupt handlers, but this would
+create conflicts because they are not normal Ada tasks. Services
+such as Set_Priority would need to treat them as a special case,
+adding the need for new checks in potentially many places.
+
+We believe that using Interrupt_ID for identifying the execution time
+clocks is compatible with the proposed approach for attaching
+interrupts to a specific processor in multiprocessor systems. It seems
+that using pseudo-task IDs instead would require defining these for
+each processor, which would add complexity to the API.
+
+Parts number 2 and 3 of this proposal define new optional Ada packages
+as "implementation advice". An alternative would be to make these
+packages mandatory if the Real-Time Annex is supported, and allow the
+implementation to provide dummy implementations for the subprograms, for
+instance clocks that always return zero (meaning that interrupt time
+is not measured) or timers which never expire (because the clocks on
+which they are based do not advance).
+Original Proposal is as follows.
+
 This proposal contains three parts, listed in order
 of importance. Each one is based on the previous one and adds new
 services that are useful to real-time applications.
@@ -160,87 +297,6 @@
 discriminant, since a task Id is not needed for interrupt execution
 time timers. This would require making the Null_Task_Id constant
 "aliased" in the Ada.Task_Identification package.
-
-
-!wording
-
-Covering the first two points above only.
-
-Add after D.14(29/2)(Implementation Advice):
-
-When appropriate, the execution time consumed by interrupt handlers
-and run-time services on behalf of the system should not be charged
-to the execution time of tasks.
-
-If the execution time consumed by interrupt handlers is accounted
-for separately from the execution time of tasks, the
-time consumed should be made available by means
-of the following language-defined library-level package:
-
-with Ada.Interrupts;
-package Ada.Execution_Time.Interrupts is
-   function Clock (I : Ada.Interrupts.Interrupt_ID)
-        return CPU_Time;
-end Ada.Execution_Time.Interrupts;
-
-The Ada.Execution_Time.Interrupts package defines one
-execution-time clock for each Interrupt_ID. The Clock function
-returns the execution time spent by interrupt handlers while
-handling the interrupt specified by I.
-
-
-!discussion
-
-This document contains a proposal to add to the Ada standard
-implementation advice on how to handle the measurement of the
-execution time of interrupt handlers separately from the execution
-time of user tasks.
-
-The most interesting aspect of the new service is that it can
-significantly enhance the accuracy of the execution time clocks and
-timers of user tasks, because they are not arbitrarily charged with
-the execution times of interrupt service handlers.
-
-This support for managing the execution time of interrupt handlers
-does not require any language modification or the addition of any new
-API. However, once the interrupt execution time is measured, it can be
-made available to Ada applications via special clocks that
-measure the execution time of the interrupt handlers associated with a
-given interrupt Id.
-
-Moreover, it is possible to extend the current execution time timers
-to use the newly defined execution time clocks for interrupt handlers,
-thus introducing the ability for the system to detect execution time
-violations in interrupt handlers.
-
-Since all this functionality may not be available on all platforms it
-is only proposed as implementation advice, to be implemented when
-appropriate.
-
-In [1] and [2] the overheads incurred by the implementation of these
-new services have been measured, and found that they are very low in
-comparison with the execution times of common interrupt
-handlers.
-
-Regarding the proposed API, it would be possible to define a Task_Id
-for pseudo tasks representing interrupt handlers, but this would
-create conflicts because they are not normal Ada tasks. Services
-such as Set_Priority would need to treat them as a special case,
-adding the need for new checks in potentially many places.
-
-We believe that using Interrupt_ID for identifying the execution time
-clocks is compatible with the proposed approach for attaching
-interrupts to a specific processor in multiprocessor systems. It seems
-that using pseudo-task IDs instead would require defining these for
-each processor, which would add complexity to the API.
-
-Parts number 2 and 3 of this proposal define new optional Ada packages
-as "implementation advice". An alternative would be to make these
-packages mandatory if the Real-Time Annex is supported, and allow the
-implementation to provide dummy implementations for the subprograms, for
-instance clocks that always return zero (meaning that interrupt time
-is not measured) or timers which never expire (because the clocks on
-which they are based do not advance).
 
 References
 ----------

Questions? Ask the ACAA Technical Agent