CVS difference for ai12s/ai12-0234-1.txt

Differences between 1.5 and version 1.6
Log of other versions for file ai12s/ai12-0234-1.txt

--- ai12s/ai12-0234-1.txt	2018/05/11 05:32:48	1.5
+++ ai12s/ai12-0234-1.txt	2018/05/18 01:58:47	1.6
@@ -2378,3 +2378,297 @@
 progress on them. And this topic is completely separate from the other issues.
 
 ****************************************************************
+
+From: Brad Moore
+Sent: Friday, May 11, 2018  6:25 PM
+
+>>   type Test_And_Set_Type is mod 2**8;
+> 
+> (1) Shouldn't this type be declared atomic (or at least volatile)? 
+> It's beyond weird to do atomic operations on non-atomic objects. (It's 
+> also a substantial optimizer problem - an Ada optimizer knows to leave 
+> atomic objects alone, but that certainly isn't the case for other 
+> objects.)
+
+I agree, it should be atomic. When I originally started out, I was trying to
+do this with ordinary integer types, since the atomic operations provided by
+the GCC API, can be applied to ordinary integers. Even in C, there is no need
+to apply a volatile pragma or anything special to the declarations. All the
+operations just take an access to a memory location, and all updates to the
+memory location are via the API calls, so it works.
+
+However, I then realized that trying to describe this in the RM was going to 
+be messy, and that it would be better to say everything is atomic, then the
+definitions for atomic get applied for free, and found it fit much better to
+do that. 
+
+I then added Atomic to all all the calls in the specs, but missed this one.
+
+> (2) 2**8 would be a very expensive type on the U2200 and various other 
+> unusual processors. Ada has never tied itself to 8-bit machines like Java.
+> Shouldn't this type be based on the storage unit in System?
+
+I agree that storage unit would be a more flexible definition. The GCC api 
+just has a void pointer, but the documentation says it updates a byte of 
+storage. I suppose one could alternatively say 2**implementation defined, like
+we do for Hash_Type in Ada.Containers, but in this case I think basing it on
+storage unit would be a better choice. I wonder if it could be a private type?
+I think I tried that, but found it harder to describe in the wording. This 
+way, one can say that Clear sets the value to a zero value.
+
+> ...
+>> To specify that the generic formals are atomic types, I needed to 
+>> change the rules to allow the Atomic aspect to be specified on a 
+>> generic formal, which previously was not allowed.
+> 
+> I wonder if this should be done in a separate AI. It could get complex 
+> if Steve discovers any more contract problems.
+
+I think a separate AI for this would be better also to separate concerns.
+
+>> Modify C.6 (6.1/3)  to allow aspect Atomic to be applied to a generic formal type
+>>
+>> For an object_declaration, a component_declaration, or a {type 
+>> (including a formal type)}[full_type_declaration], the following 
+>> representation aspects may be specified:
+> 
+> (1) This implies that Atomic can be specified in private types, 
+> extensions, interfaces, incomplete types, yadda yadda yadda. The 
+> Legality Rules in 13.1 for representation aspects would prevent that, 
+> but those same rules also would prevent use on formal types "unless 
+> otherwise specified". Seems confused. I'd suggest just adding 
+> "formal_type_declaration" to the original list and then there is no
+> confusion nor any need for a parenthetical remark.
+> 
+>  For an object_declaration, a component_declaration, 
+> {full_type_declartion}, or a  {formal}[full]_type_declaration, the 
+> following representation aspects may be
+>  specified:
+
+I agree with your suggestion. I think I got the original wording idea by 
+looking at what was done for the Nonblocking aspect, since it can be 
+applied to generic formals.
+
+> (2) This means all 6 aspects are getting allowed on formal types, even 
+> though we only have need (and rules!) for one. Is that really what we want?
+> Do we really want to mess around with Independent_Components in generics?
+> Etc.
+
+I think I was under the impression that I was letting Volatile ride in on the 
+coattails of Atomic for this purpose, but didn't think the other ones were 
+being included. The thought was that it probably makes sense to allow Volatile
+on generic formal types, or weird not to, if we allow Atomic. But only if it 
+fits better with the wording. Otherwise restricting it to just Atomic is fine 
+by me.
+
+>>Modify C.6 (12/3)
+>>If an atomic object is passed as a parameter, then the formal parameter
+>>shall either have an atomic type or allow pass by copy. If an atomic object
+>>is used as an actual for a generic formal object of mode in out, then the
+>>type of the generic formal object shall be atomic. If the prefix of an
+>>attribute_reference for an Access attribute denotes an atomic object
+>>[(including a component)], then
+>>the designated type of the resulting access type shall be atomic. {If a
+>>generic formal type is atomic, then the actual shall be atomic.} If an
+>>atomic type is used as an actual for a generic formal derived type,
+>>then the ancestor of the formal type shall be atomic. Corresponding rules 
+>>apply to volatile objects and types.
+
+>>In a generic instantiation the actual type corresponding to an atomic
+>>formal scalar, private, derived, array, or access-to-object type shall be 
+>>atomic;
+> 
+> Could you explain why you are saying this twice, once with an added 
+> sentence in the original paragraph, and a second time with an added 
+> paragraph. It seems like the first added rule would be enough, but 
+> perhaps I missed some subtle issue.
+
+Sure. I said it the first time because that is what I thought was needed. Then
+I saw somewhere (probably nonblocking aspect) that needed to describe generic
+matching rules for instances and looked up an example of that (again, likely 
+from nonblocking aspect), which is where I got the second version of the 
+statement.  The intent was that we could get rid of one or the other, or merge
+into one. I wasn't sure if the second was more of a boilerplate that was
+needed for generic instances, and also if it had some subtlety not captured
+in the first time. Otherwise I dont have a real reason for stating it the 
+second time. If you don't think it is needed, we can get rid of it.
+
+>> Finally, in addition, since protected objects on a single processor 
+>> are considered to be lock-free and deadlock free with appropriate use 
+>> of the ceiling priority protocol, this AI also extends the rules for 
+>> the CPU aspect, so that it can be applied to protected type 
+>> declarations. The compiler can simplify the implementation for such 
+>> protected types, since locking is not needed, plus there is the added 
+>> benefit of being deadlock free, which was considered to be important 
+>> by the attendees at the recent IRTAW, which unanimously felt it was 
+>> worth adding to the standard.
+> 
+> This also seems like it ought to have been a separate AI, even more so 
+> than the formal Atomic types. As you know, when AIs get too big, it's 
+> hard to make progress on them. And this topic is completely separate 
+> from the other issues.
+
+I agree that this really should be a separate AI. I think I was thinking at 
+the time that it would be more likely to be considered if part of an existing
+AI, and it is related to the topic of lock-free, so it kind of fits somewhat.
+I thought that adding a new AI at this stage might be been disallowed, but if
+that can be done, given that IRTAW was behind it, then I agree that is a 
+better way to go. 
+
+Would you like me to resubmit this as 3 separate AI's?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, May 11, 2018  9:03 PM
+
+...
+> >>In a generic instantiation the actual type corresponding to an 
+> >>atomic  formal scalar, private, derived, array, or access-to-object 
+> >>type shall be atomic;
+> > 
+> > Could you explain why you are saying this twice, once with an added 
+> > sentence in the original paragraph, and a second time with an added 
+> > paragraph. It seems like the first added rule would be enough, but 
+> > perhaps I missed some subtle issue.
+> 
+> Sure. I said it the first time because that is what I thought was 
+> needed. Then I saw somewhere (probably nonblocking
+> aspect) that needed to describe generic matching rules for instances 
+> and looked up an example of that (again, likely from nonblocking 
+> aspect), which is where I got the second version of the statement.
+> The intent was that we could get rid of one or the other, or merge 
+> into one. I wasn't sure if the second was more of a boilerplate that 
+> was needed for generic instances, and also if it had some subtlety not 
+> captured in the first time.
+> Otherwise I dont have a real reason for stating it the second time. If 
+> you don't think it is needed, we can get rid of it.
+
+I believe the Nonblocking rule was written the way it was because it does
+*not* apply to generic discrete (or is it scalar?) types. So I had to mention
+what it *did* apply to, as opposed to just saying it always applied.
+If your rule applies to all types, it's just really long-winded for no reason.
+
+...
+> I agree that this really should be a separate AI. I think I was 
+> thinking at the time that it would be more likely to be considered if 
+> part of an existing AI, and it is related to the topic of lock-free, 
+> so it kind of fits somewhat. I thought that adding a new AI at this 
+> stage might be been disallowed, but if that can be done, given that 
+> IRTAW was behind it, then I agree that is a better way to go.
+
+I haven't sent the list to WG 9 yet, so IRTAW can add new things until I get 
+caught up posting AIs. (Almost there, but not quite.) And you could probably 
+make a case for it to be related to our instructions, but even if not, a split
+of an already started AI is always in-bounds. 
+ 
+> Would you like me to resubmit this as 3 separate AI's?
+
+Yes please. Remember to mention that in the existing AI12-0234-1 part (the 
+actual packages) that you're depending on AI12-028x-1. (I just finished 277,
+and I have four more to post/write, so the number should be in the 280s.)
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Monday, May 14, 2018  1:34 PM
+
+> Would you like me to resubmit this as 3 separate AI's?
+
+Yes please, three separate AIs would seem sensible to me too.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, May 14, 2018  10:09 PM
+
+I didn't say anything about the first two items here, and I probably should have.
+
+...
+> > (2) 2**8 would be a very expensive type on the U2200 and various 
+> > other unusual processors. Ada has never tied itself to 8-bit 
+> > machines like Java.
+> > Shouldn't this type be based on the storage unit in System?
+> 
+> I agree that storage unit would be a more flexible definition. The GCC 
+> api just has a void pointer, but the documentation says it updates a 
+> byte of storage.
+> I suppose one could alternatively say 2**implementation defined, like 
+> we do for Hash_Type in Ada.Containers, but in this case I think basing 
+> it on storage unit would be a better choice. I wonder if it could be a 
+> private type? I think I tried that, but found it harder to describe in 
+> the wording.
+> This way, one can say that Clear sets the value to a zero value.
+
+Perhaps you just want to copy (literally) the definition of Storage_Element 
+(which is modular):
+
+   type Test_And_Set_Type is mod System.Storage_Elements.Storage_Element'Modulus
+      with Atomic;
+
+(We can't use Storage_Element directly because of the need to declare this 
+atomic, but we can copy the modulus. Storage_Unit is defined to be
+Storage_Element'Size.)
+
+...
+> > (2) This means all 6 aspects are getting allowed on formal types, 
+> > even though we only have need (and rules!) for one. Is that really 
+> > what we want?
+> > Do we really want to mess around with Independent_Components in generics?
+> > Etc.
+> 
+> I think I was under the impression that I was letting Volatile ride in 
+> on the coattails of Atomic for this purpose, but didn't think the 
+> other ones were being included.
+> The thought was that it probably makes sense to allow Volatile on 
+> generic formal types, or weird not to, if we allow Atomic. But only if 
+> it fits better with the wording.
+> Otherwise restricting it to just Atomic is fine by me.
+
+That seemed OK to me, but what about Atomic_Components and Volatile_Components
+on formal array types? That seems like work :-) and I don't know if we have 
+any use for that work. And similarly for the Independent cases.
+
+>Would you like me to resubmit this as 3 separate AI's?
+
+Repeating myself, Yes. AI12-0234-1 would be the generic packages (since that 
+is the original question), the formal type one is needed to support that 
+original one, and the third is just a good idea on its own. Those will get
+numbers when I get them. All three will appear at the place of AI12-0234-1
+in our priority order (at least initially), since there isn't anything else
+to use to give them an order.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, May 14, 2018  11:40 PM
+
+> ...
+> > > (2) This means all 6 aspects are getting allowed on formal types, 
+> > > even though we only have need (and rules!) for one. Is that really 
+> > > what we want?
+> > > Do we really want to mess around with Independent_Components in generics?
+> > > Etc.
+> > 
+> > I think I was under the impression that I was letting Volatile ride 
+> > in on the coattails of Atomic for this purpose, but didn't think the 
+> > other ones were being included.
+> > The thought was that it probably makes sense to allow Volatile on 
+> > generic formal types, or weird not to, if we allow Atomic. But only 
+> > if it fits better with the wording.
+> > Otherwise restricting it to just Atomic is fine by me.
+> 
+> That seemed OK to me, but what about Atomic_Components and 
+> Volatile_Components on formal array types? That seems like work :-) 
+> and I don't know if we have any use for that work.
+> And similarly for the Independent cases.
+
+Humm, I see that the actual wording only uses that heading for the three 
+aspects Atomic, Volatile, and Independent. But the proposed wording literally
+only has rules for Atomic and Volatile. There's no wording for what it meaning
+to put Independent into a formal type, but the proposed wording allows it. We 
+need at a minimum to reconcile this (either have wording for generic matching 
+for Independent, or only allow on formals for Atomic and Volatile).
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent