!standard D.07(09) 05-11-15 AI95-00394/05 !standard D.07(10) !standard D.07(15) !standard D.13.1(01) !standard H.4(2) !standard H.4(3) !standard H.4(9) !standard H.4(16) !standard H.4(23) !standard J.13(1) !class amendment 05-01-20 !status Amendment 200Y 05-02-25 !status ARG Approved 9-0-1 05-02-13 !status work item 05-01-20 !status received 05-01-20 !priority High !difficulty Easy !subject Redundant Restriction Identifiers and completing Ravenscar definition !summary This AI moves existing restriction identifiers to Annex J, and modifies the definition of the Ravenscar profile. It also completes the definition of the Ravenscar profile by including new restrictions that concern new features of the language. !problem The new restriction identifier, No_Dependence, has made existing identifiers redundant and allows the Ravenscar profile to be defined without the need to introduce further new identifiers. It also makes AI-353 redundant, and a number of new restriction identifiers in AI-305. To complete the definition of Ravenscar it is necessary to restrict the use of the following new features: 1. CPU Timers 2. Group Timers 3. Specific handlers for task termination. The first two are restricted due to their incompatibility with Ravenscar; the events they define identify dynamic actions that Ravenscar cannot easily utilize. The required restrictions are obtained by the use of restriction identifier No_Dependence. As tasks in Ravenscar are not intended to terminate (and are all at the library level) it is deemed adequate for there to be only a fall-back handler. The run-time will be simpler if specific handlers are not supported. To define this restriction a new restrictions identifier is defined: No_Specific_Termination_Handlers. To make it clear that if a Ravenscar task does terminate the fall-back handler (if there is one) will be executed, the definition of No_Task_Termination is modified. Finally, it was noted that the phrase "restriction xxx apply in this Annex" doesn't make much sense. The wording was revised to eliminate this phrase. !proposal (See wording.) !wording Delete (the original) D.7(10), H.4(9), and H.4(16). Delete No_Calendar and No_Task_Attributes_Package from the wording changes of AI-305. AI-353 should be dropped from the Amendment. Add new Section in Annex J: J.13 Dependence Restriction Identifiers The following restrictions involve dependence on specific language-defined units. The more general No_Dependence restriction should be used for this purpose. Static Semantics The following restriction_identifiers exist: No_Asynchronous_Control Semantic dependence on the predefined package Asynchronous_Task_Control is not allowed. No_Unchecked_Conversion Semantic dependence on the predefined generic function Unchecked_Conversion is not allowed. No_Unchecked_Deallocation Semantic dependence on the predefined generic procedure Unchecked_Deallocation is not allowed. Delete H.4(2). Change H.4(3) to read: The following restriction_identifiers are language defined: Add the following before H.4(24): An implementation of this Annex shall support: o the restrictions defined in this subclause; and o the following uses of restriction_parameter_identifier No_Dependence defined in 13.12.1: No_Dependence => Ada.Unchecked_Deallocation and No_Dependence => Ada.Unchecked_Conversion; and o the following restrictions defined in D.7: No_Task_Hierarchy, No_Abort_Statement, No_Implicit_Heap_Allocation; and o the following uses of restriction_parameter_identifiers defined in D.7, which are checked prior to program execution: Max_Task_Entries => 0, Max_Asynchronous_Select_Nesting => 0, and Max_Tasks => 0; and o the pragma Profile(Ravenscar). Add the following new static restriction_identifier after D.7(10): No_Specific_Termination_Handlers There are no calls to the following subprograms in Task_Termination: Set_Specific_Handler and Specific_Handler. Modify the definition of restriction_identifier in AI-305 to the following: No_Task_Termination All tasks are non-terminating. It is implementation-defined what happens if a task attempts to terminate. If there is a fall-back handler (see C.7.3) set for the partition it should be called when the first task attempts to terminate. The static semantic section of the Ravenscar profile definition (in AI-249) becomes: Static Semantics The run-time profile Ravenscar is equivalent to the following set of pragmas: pragma Task_Dispatching_Policy (FIFO_Within_Priorities); pragma Locking_Policy (Ceiling_Locking); pragma Detect_Blocking; pragma Restrictions ( No_Abort_Statements, No_Dynamic_Attachment, No_Dynamic_Priorities, No_Implicit_Heap_Allocations, No_Local_Protected_Objects, No_Local_Timing_Events, No_Protected_Type_Allocators, No_Relative_Delay, No_Requeue_Statements, No_Select_Statements, No_Specific_Termination_Handlers, No_Task_Allocators, No_Task_Hierarchy, No_Task_Termination, Simple_Barriers, Max_Entry_Queue_Length => 1, Max_Protected_Entries => 1, Max_Task_Entries => 0, No_Dependence => Ada.Asynchronous_Task_Control, No_Dependence => Ada.Calendar, No_Dependence => Ada.Execution_Time.Group_Budget, No_Dependence => Ada.Execution_Time.Timers, No_Dependence => Ada.Task_Attributes); !discussion The identifier No_IO covers a set of library packages and thus was not moved to Annex J. The identifier No_Dynamic_Priorities was extended by AI-327 to cover uses of the Priority attribute for protected objects as well as dependencies on Ada.Dynamic_Priorities. Thus it was not moved to Annex J. The minimum requirement for task termination when No_Task_Termination is in force is to ensure that any fall-back handler is executed at least once. Given that no tasks are meant to terminate this would seem to be sufficient. !corrigendum D.7(10) !comment The AI-305 changes are made in the conflict text only. @drepl @xhang<@xterm There are no semantic dependences on the package Asynchronous_Task_Control.> @dby @xhang<@xterm There are no calls to the Set_Specific_Handler and Specific_Handler subprograms in Task_Termination. !corrigendum D.7(15) @drepl @i @dby The following @I@fas are language defined: @xhang<@xterm All tasks are non-terminating. It is implementation-defined what happens if a task attempts to terminate. If there is a fall-back handler (see C.7.3) set for the partition it should be called when the first task attempts to terminate.> !corrigendum D.13.1(01) @dinsc This clause defines the Ravenscar profile. @i<@s8> The @i@fa Ravenscar names a run-time profile. For run-time profile Ravenscar, there shall be no @i@fas. @i<@s8> The run-time profile Ravenscar is equivalent to the following set of pragmas: @xcode<@b Task_Dispatching_Policy (FIFO_Within_Priorities); @b Locking_Policy (Ceiling_Locking); @b Detect_Blocking; @b Restrictions ( No_Abort_Statements, No_Dynamic_Attachment, No_Dynamic_Priorities, No_Implicit_Heap_Allocations, No_Local_Protected_Objects, No_Local_Timing_Events, No_Protected_Type_Allocators, No_Relative_Delay, No_Requeue_Statements, No_Select_Statements, No_Specific_Termination_Handlers, No_Task_Allocators, No_Task_Hierarchy, No_Task_Termination, Simple_Barriers, Max_Entry_Queue_Length =@> 1, Max_Protected_Entries =@> 1, Max_Task_Entries =@> 0, No_Dependence =@> Ada.Asynchronous_Task_Control, No_Dependence =@> Ada.Calendar, No_Dependence =@> Ada.Execution_Time.Group_Budget, No_Dependence =@> Ada.Execution_Time.Timers, No_Dependence =@> Ada.Task_Attributes);> @xindent<@s9 1 restriction applies only to protected entry queues due to the accompanying restriction of Max_Task_Entries =@> 0.>> !corrigendum H.4(2) @ddel The following restrictions, the same as in D.7, apply in this Annex: No_Task_Hierarchy, No_Abort_Statement, No_Implicit_Heap_Allocation, Max_Task_Entries is 0, Max_Asynchronous_Select_Nesting is 0, and Max_Tasks is 0. The last three restrictions are checked prior to program execution. !corrigendum H.4(3) @drepl The following additional restrictions apply in this Annex. @dby The following @i@fas are language defined: !corrigendum H.4(9) @ddel @xhang<@xterm Semantic dependence on Unchecked_Deallocation is not allowed.> !corrigendum H.4(16) @ddel @xhang<@xterm Semantic dependence on the predefined generic Unchecked_Conversion is not allowed.> !corrigendum H.4(24) @dinsb If an implementation supports pragma Restrictions for a particular argument, then except for the restrictions No_Unchecked_Deallocation, No_Unchecked_Conversion, No_Access_Subprograms, and No_Unchecked_Access, the associated restriction applies to the run-time system. @dinst An implementation of this Annex shall support: @xbullet @xbullet@fa No_Dependence defined in 13.12.1: No_Dependence =@> Ada.Unchecked_Deallocation and No_Dependence =@> Ada.Unchecked_Conversion; and> @xbullet @xbullet@fas defined in D.7, which are checked prior to program execution: Max_Task_Entries =@> 0, Max_Asynchronous_Select_Nesting =@> 0, and Max_Tasks =@> 0; and> @xbullet Profile(Ravenscar).> !corrigendum J.13(1) @dinsc The following @fa involve dependence on specific language-defined units. The more general restriction No_Dependence (see 13.12.1) should be used for this purpose. @i<@s8> The following @i@fa exist: @xhang<@xterm Semantic dependence on the predefined package Asynchronous_Task_Control is not allowed.> @xhang<@xterm Semantic dependence on the predefined generic function Unchecked_Conversion is not allowed.> @xhang<@xterm Semantic dependence on the predefined generic procedure Unchecked_Deallocation is not allowed.> !ACATS test This AI should be covered by tests for the Ravenscar profile. !appendix From: Alan Burns Sent: Tuesday, January 4, 2005 8:50 AM As part of integration it is necessary to identify those new language features that can be used with Ravenscar, and more importantly those that cannot. I have organized a series of emails around the IRTAW email list and have complete agreement with the following. First what we already covered in the AIs; restriction identifier No_Local_Timing_Events and the inclusion of no dynamic ceilings in the no dynamic priority restriction identifier. In terms of the budgeting provisions, the IRTAW view is that Ada.Execution_Time is a very important package for ravenscar-like programs, but Ada.Execution_Time.Timers and Ada.Execution_Time.Group_Budgets do not sensible co-exist with the other restrictions of Ravenscar and so should be prohibited. Its is therefore necessary to add two further restrictions to Ravenscar. But we can do this in two ways; either by introducing two new restriction identifiers, or by using the new provision by which any language defined library package can be restricted. I'll let Pascal or Randy decide this - or perhaps we need a short discussion at the Paris meeting? **************************************************************** From: Robert Dewar Sent: Tuesday, January 4, 2005 9:42 AM Please don't add more junk restrictions, when pragma No_Dependence takes care ot if. In fact here is an idea, move all the specific package restrictions to annex J! **************************************************************** From: Pascal Leroy Sent: Tuesday, January 4, 2005 11:13 AM I agree with Robert here: don't add new restrictions, and move the existing ones to J. **************************************************************** From: Randy Brukardt Sent: Tuesday, January 4, 2005 1:20 PM Absolutely: that's the reason we defined it; we didn't want a dozen new dependence restrictions. Moving the existing ones to Annex J makes sense. Who's going to write the AI (it should be easy)? **************************************************************** From: Alan Burns Sent: Wednesday, January 5, 2005 5:35 AM I am happy to do this - but are we clear that all existing package specific restriction identifiers should be moved to Annex J - anyone disagree? **************************************************************** From: John Barnes Sent: Wednesday, January 5, 2005 9:47 AM Presumably we can do nothing about No_Dynamic_Attachment since dependence means children also and we need Ada.Interrupts.Names. **************************************************************** From: Robert Dewar Sent: Wednesday, January 5, 2005 10:09 AM I don't understand, pragma Restrictions (No_Dependence => Ada.Dynamic_Priorites); seems to exactly catch the intent of the No_Dynamic_Attachment restriction: 9 No_Dynamic_Priorities There are no semantic dependences on the package Dynamic_ Priorities. I really don't see what Ada.Interrupts.Names has to do with this. **************************************************************** From: John Barnes Sent: Wednesday, January 5, 2005 2:02 PM AI-305 says No_Dynamic_Attachment There is no call to any of the operations defined in package Ada.Interrupts. **************************************************************** From: Robert Dewar Sent: Wednesday, January 5, 2005 4:14 PM SOrry, I misread, yes, of course No_Dynamic_Attachment has nothing whatever to do with avoiding package dependences, so it is nothing whatever to do with No_Dependence. **************************************************************** From: Arnuad Charlet Sent: Wednesday, January 19, 2005 5:10 AM BTW, have we discussed/addressed the issue of interfaces to protected objects and tasks in the context of Ravenscar ? I assume that if we don't do anything, these will be by default part of Ravenscar. Is that what we want ? **************************************************************** From: Alan Burns Sent: Wednesday, January 19, 2005 6:42 AM interfaces are compile time constructs, so they do not impact on Ravenscar which is concerned with run-time issues **************************************************************** From: Arnuad Charlet Sent: Wednesday, January 19, 2005 6:52 AM interfaces do have run time impact, in particular dynamic dispatching. But from your message, I gather that nothing special has been discussed nor will be changed wrt ravenscar. It would still be good to update the ravenscar definition to explicitely mention protected and task interfaces IMO. **************************************************************** From: Steve Michell Sent: Thursday, January 20, 2005 8:48 AM I agree that the issue of interfaces should be discussed, and our compiler specialists should voice an opinion. Since all task specifications and objects reside at the library level, and since there is no way to dereference a task (entries are forbidden) from the caller's perspective, there should be no run-time dynamic issues, apart from possibly at partition start time. For PO specs and objects, they also reside at the library level, so it should be possible to statically resolve all references, or we should be able to figure out how to statically resolve the references and create a restriction that matches this. I do agree with Arnaud that Ravenscar needs to specifically mention task and protected interfaces, positively or negatively, to remove the ambiguity in developers minds. **************************************************************** From: Alan Burns Sent: Thursday, January 20, 2005 9:59 AM This sound more like a note for the AARM - Steve can you produce one? **************************************************************** From: Randy Brukardt Sent: Thursday, January 20, 2005 5:52 PM > For PO specs and objects, they also reside at the library level, > so it should be possible to statically resolve all references, or > we should be able to figure out how to statically resolve the > references and create a restriction that matches this. As soon as you allow I'Class, you're going to have dynamic references. It doesn't matter where the objects are declared, because they still can be passed as an I'Class parameter. You could of course restrict I'Class, but, since the whole point of interfaces is to get dynamic dispatching, a controlled form of dynamic references, it wouldn't be very useful to do so. So, if all references must be static, I would just ban synchronized interfaces (they can't do any real good) -- but barring that, you'd have to ban I'Class for all synchronized interfaces. I would hope that the limited and controlled dynamism inherent in synchronized interfaces could be allowed, but that is obviously a question for real-time experts (not me!) to answer. And it will take more effort than an AARM note to figure out. **************************************************************** From: Alan Burns Sent: Friday, January 21, 2004 3:03 AM As you know Ravenscar is silent about the sequential parts of the language, and hence make no statement about memory usage in general (eg class wide stuff). The use of Ravenscar in a critical domain is likely to also have added restrictions to the sequential features. In Ada2005 this would include use of interfaces in general. So Ravenscar does not in itself require references to be static. Now task, protected and synchronized interfaces are undoubted about the concurrent parts of the language, but I feel their acceptability is more an issue for the decisions made about references in general. Hence I feel Ravenscar should be silent about them with an AARM note covering the consequences of using such interfaces in a Ravenscar program. **************************************************************** From: Randy Brukardt Sent: Thursday, January 20, 2005 5:38 PM I'm a bit uncomfortable moving the No_IO restriction to Annex J. It covers six units, and it would be really easy to forget one of them. Moreover, it is less subject to maintenance than all of those No_Dependence pragmas - people using it won't have to make any changes to handle the introduction of Really_Darn_Wide_Text_IO, er, Wide_Wide_Text_IO. Looking at it, I'm a bit surprised that it doesn't include implementation-defined I/O units. I would have expected it to prevent the use of System.Basic_IO on Janus/Ada, for example, as that is just a lower-level file I/O package. (The list of implementation-defined I/O units would of course be defined by the implementation; the intent would be that packages similar in function to the predefined I/O units be covered.) The wording of the restriction doesn't seem to permit the implementation to add implementation-defined units to the restriction -- which would add value to the restriction beyond simple No_Dependence. I would leave it in Annex H and allow it to cover implementation-defined I/O units. (The units covered would have to be documented, of course.) **************************************************************** From: Robert Dewar Sent: Thursday, January 20, 2005 5:50 PM > The > wording of the restriction doesn't seem to permit the implementation to add > implementation-defined units to the restriction -- which would add value to > the restriction beyond simple No_Dependence. Sure you can add this, what would stop you, if your implementation provides a package, it does not have to do it all the time. It would be perfectly conforming to have a package that is only available in leap years. Yes, that would be stupid, but non-stupid examples like this are certainly allowed. > I would leave it in Annex H That's OK with me > and allow it to cover implementation-defined I/O > units. (The units covered would have to be documented, of course.) IA that this should include implementation defined I/O units is reasonable. Of course you might have limited I/O units that were specificially designed to be used in *conjunction* with this restriction. **************************************************************** From: Randy Brukardt Sent: Thursday, January 20, 2005 6:01 PM > IA that this should include implementation defined I/O units is > reasonable. That's what I had in mind. Something like: "No_IO also should not allow semantic dependence on implementation-defined Input/Output units similar in function to the language-defined units listed." > Of course you might have limited I/O units that were specificially designed > to be used in *conjunction* with this restriction. Absolutely. Thus the "similar in function", and of course, IA can always be ignored. **************************************************************** From: Robert A. Duff Sent: Thursday, January 20, 2005 7:22 PM > Re: No_IO > > I'm a bit uncomfortable moving this restriction to Annex J. It covers six > units, and it would be really easy to forget one of them. I agree. **************************************************************** From: Jean-Pierre Rosen Sent: Friday, January 21, 2005 3:39 AM > I'm a bit uncomfortable moving this restriction to Annex J. It covers six > units, and it would be really easy to forget one of them. Moreover, it is > less subject to maintenance than all of those No_Dependence pragmas - people > using it won't have to make any changes to handle the introduction of > Really_Darn_Wide_Text_IO, er, Wide_Wide_Text_IO. > What you are saying is that No_IO is more a *profile* than a single restriction. If a profile can include another profile, that would do the trick. **************************************************************** From: Randy Brukardt Sent: Monday, February 28, 2005 8:45 PM The recently approved AI-394 banishes several restrictions to Annex J in favor of using the new No_Dependence restriction. One of the restrictions so banished is No_Dynamic_Priorities: No_Dynamic_Priorities There are no semantic dependences on the package Dynamic_Priorities. However, AI-327 extended this restriction to: No_Dynamic_Priorities There are no semantic dependences on the package Dynamic_Priorities, and no occurrences of the attribute Priority. This covers the dynamic changing of ceiling priorities for protected objects. It seems to me that this still needs to be disallowed by profile Ravenscar, so it seems that someone fell asleep at the switch. I think that we need to put this back the way it was in AI-327, and leave this restriction in the Ravenscar profile, rather than use No_Dependence. Is this right?? **************************************************************** From: Robert Dewar Sent: Tuesday, March 1, 2005 12:00 AM Yes, that's indeed right **************************************************************** From: Alan Burns Sent: Tuesday, March 1, 2005 2:33 AM ... > This covers the dynamic changing of ceiling priorities for protected > objects. It seems to me that this still needs to be disallowed by profile > Ravenscar, so it seems that someone fell asleep at the switch. Well that would be me - yes totally missed this interaction Obviously i would have noticed it later ... > I think that we need to put this back the way it was in AI-327, and leave > this restriction in the Ravenscar profile, rather than use No_Dependence. > Is this right?? YES **************************************************************** From: Pascal Leroy Sent: Tuesday, March 1, 2005 3:31 AM > I think that we need to put this back the way it was in > AI-327, and leave this restriction in the Ravenscar profile, > rather than use No_Dependence. Is this right?? Yes. **************************************************************** From: Randy Brukardt Sent: Tuesday, March 1, 2005 4:22 PM > Well that would be me - yes totally missed this interaction > Obviously i would have noticed it later ... Don't feel bad, I only noticed it because the tool that makes the Amendment document produced an error message. I'll process this as a correction to AI-394. ****************************************************************