CVS difference for ai05s/ai05-0009-1.txt
--- ai05s/ai05-0009-1.txt 2006/11/14 00:06:28 1.2
+++ ai05s/ai05-0009-1.txt 2007/05/24 01:17:40 1.3
@@ -1,4 +1,4 @@
-!standard 9.10(1) 06-11-06 AI05-0009-1/02
+!standard 9.10(1) 07-05-20 AI05-0009-1/03
!class binding interpretation 06-03-21
!status work item 06-03-21
!status received 06-02-20
@@ -9,11 +9,14 @@
!summary
-A new pragma Independent_Components allows a user to specify that the components
-of an object or type should be independently addressable.
-
-Objects or types that have a convention specified by an interfacing pragma may not
-be independently addressable.
+The incorporation of confirming representation clauses has
+semantic implications for independent addressability.
+Two new pragmas (Independent and Independent_Components) to allow a user
+to specify that the components of an object or type should be
+independently addressable. Additionally, objects or types that have a
+convention (other than Ada) specified by an interfacing pragma have
+been added to the kinds of representation items that impact
+independent addressability.
!question
@@ -24,116 +27,124 @@
!recommendation
-Insert "nonconfirming" into 9.10(1). Add "convention" to the list of aspects that
-do not require independence.
+Modify 9.10 to identify only non-confirming representations as those
+that can cause dependent addressability. Modify to include
+convention as an item that can cause an object to be dependent
+(exclude convention Ada) for a representation. Change dependent
+addressability from implementation defined to unspecified.
+
+Add pragmas Independent and Independent_Components to C.6. Independent
+applies to components of record types; Independent_Components
+applies to components of arrays or anonymous array objects.
-Add pragma Independent_Components (type_local_NAME); which specifies that
-independence must be guaranteed for the given type. The pragma must be rejected
-if independence cannot be guaranteed. Add implementation advice for independently
-addressable objects.
+Also update the AARM notes in 13.1 (8.v, 8.w; 8.gg, 8.hh) to add the
+new pragmas independent and independent components.
-Modify 13.1 (21.1/2) include independently addressable components for confirming
-representations.
-
!wording
-Replace 9.10(1) with:
+Modify 9.10 (1) to read:
If two different objects, including nonoverlapping parts of the same
object, are independently addressable, they can be manipulated
concurrently by two different tasks without synchronization.
-Normally, any two nonoverlapping objects are independently
-addressable. However, if packing, record layout, Component_Size, or
-convention is specified for a given composite object, then it is
-implementation defined whether or not two nonoverlapping parts of
-that composite object are independently addressable. Pragma
-Independent_Components may be used to specify that components are
-independently addressable.
+Normally, any two nonoverlapping objects are independently addressable.
+However, if a non-confirming representation item is used to specify
+packing, record layout, Component_Size, or a convention other than Ada,
+then the independent addressability of the object (and subcomponents)
+is unspecified.
+
+Add or modify C.6 as follows:
-Syntax
+Add to Syntax
-The form of a pragma Independent_Components is as follows:
+pragma Independent (
+ [Entity => ] local_name
+ {,[Component =>] *component*_local_name});
-pragma Independent_Components (
- [Entity => ] local_name
- {,[Component =>] *component*_local_name});
+Pragma Independent_Components(*array*_local_name);
-Name Resolution Rules
+An *independent component* is a component to which a pragma Independent
+or pragma Independent_Components applies.
-The local_name in a Independent_Components pragma shall resolve to
-denote a composite type, an anonymous array object or an object to
-which an interface pragma applies.
+Modify Name Resolution
-Legality Rules
+The local_name in an Atomic or Volatile pragma shall resolve to denote
+either an object_declaration, a non-inherited component_declaration,
+or a full_type_declaration. The local_name in an Independent pragma shall
+resolve to denote a full_type_declaration of a record_type_definition; the
+*component*_local_name shall resolve to denote a non-inherited component
+of the full_type_declaration. The *array*_local_name in an
+Atomic_Components, Volatile_Components or Independent_Components
+pragma shall ...
-It is illegal to apply a Independent_Components pragma to an object
-or type if the implementation cannot support independently
-addressable components for the object or type.
+Add to Legality Rules
-Static Semantics
+It is illegal to apply a pragma Independent or Independent_Components
+to an independent component when the component is not independently
+addressable.
-Pragma Independent_Components specifies that the named components
-(or all components if none are named) are independently addressable.
+If a pragma Independent or Independent_Components applies to a generic
+formal type, then the actual type must have independent components.
-Pragma Independent_Components is a representation pragma.
+Add to Static Semantics
-Add after 9.10(15):
+An independent component is independently addressable.
-Implementation Advice
+!discussion
-The recommended level of support for independently addressable
-objects is:
+The problem to be addressed is demonstrated by the following (on a
+byte addressable target):
-* The implementation should use an indivisible operation to update
- the elementary independently addressable parts of an object when
- the target hardware provides such an operation.
+ A : array (1..4) of character;
+ for A'Component_Size use 8;
-* The implementation should avoid update of other objects or other
- subcomponents of the same object when updating an independently
- addressable part of an object. However, sequential updates of
- subcomponents of an object may be combined into a single operation.
+The components of A are no longer independent, which allows different
+encodings of the following statements:
-Replace 13.1(21.1/2) with:
+A (1) := <char>;
+A (4) := <char>;
-A confirming representation item should be supported, where
-components (if any) are independently addressable.
+Independent Sequence:
+Store <char> to A (1)
+Store <char> to A (4)
-!discussion
+Dependent Sequence:
-The intent of AI95-291-2 is that confirming representation clauses can always be given
-(assuming that it is possible to write them) without changing the semantics.
+Load 32-bit register with A
+Set MSB to <char>
+Set LSB to <char>
+Store 32-bit register to A
-Convention can affect independence; if the foreign representation is one that cannot
-guarantee independence, we don't want to have to reject the representation clause.
+The dependent sequence is disallowed when pragma Independent_Components
+applies to A on the byte addressable machine; on a word addressable
+machine the pragma would be rejected because each component of
+A is not independently addressable.
-Convention was added to the list of representation items impacting
-addressability rather than creating an explicit statement identifying
-convention as dependently addressable to avoid creating a special
-case (not as recommended in the Porto minutes). Addition of
-convention requires the inclusion of objects as parameters to the
-pragmas.
-
-9.10(16)
-
-The provision to allow multiple writes to the same object provides
-for those target architectures that do not support a single write
-instruction for large elementary objects, such as IEEE 754 Long
-Floats.
-
-9.10 (17)
-
-The implementation advice places a constraint on the use of a
-"Block Move" operation to copy data: an unaligned store operation
-must avoid the partial update of a subcomponent.
-
-!ACATS test
-
-Since it is implementation-defined if any two objects are independently addressable,
-it would be hard to create a test which tested this on all targets. Moreover, we're
-talking about confirming rep. clauses, which also are implementation-defined in
-general. So it doesn't seem possible to test this. [Suggestions welcome - RLB]
+9.10 (1)
+Including non-confirming removes semantics associated with confirming
+representations. Convention was added to allow dependent addressability
+for conventions other than Ada.
+
+C.6
+
+Introduces the new pragmas, defining independent to be applicable to
+all record types, except arrays which will require Independent_Components.
+Pragma independent and Independent_Components are similar to Volatile and
+Atomic in that only a single entity name is accepted with the pragma
+(conflicts with 13.1 (5/1, 6/1)).
+
+The minutes from Albuquerque identify that pragma independent_components
+should be considered for all composite types; however, there is no way
+to remove independence for the components of tasks or protected types,
+so the pragma was not allowed for tasks and protected types.
+
+ACATS Tests
+
+ACATS tests can be generated that would verify the rejection of the pragmas
+for all but bit-addressable architectures (TBD). The verification of code
+generation is target dependent and probably can't be effectively tested.
!appendix
@@ -1968,6 +1979,212 @@
example). There is no exception to this rule! We're surely not going to
distribute some goofy rules about independent addressibility all over the
standard.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, May 20, 2007 10:01 PM
+
+> Modify to identify only non-confirming representations as those
+> that can cause dependent addressability. Modify to include
+> convention as an item that can cause an object to be dependent
+> (exclude convention Ada) for a representation. Change dependent
+> addressability from implementation defined to unspecified.
+
+I don't think this is tenable. What on earth is the semantic
+definition of a confirming representation clause. After all
+there is nothing in the standard that prevents a compiler
+from basing the representation of an item on the phases
+of the moon, or the MD-5 checksum of the program (the latter
+ensuring that the would-be default representation is changed
+by adding "confirming rep clauses". Also it may simply not
+be possible from a formal point of view to specify a confirming
+rep clause, e.g. suppose that an array is by default stored
+in some sparse hash table form, and only has a meaningful
+component size if one is specified, or if the component size
+is queried. etc etc.
+
+At most this could be implementation advice
+
+I do not see why convention should possibly affect independence
+>
+> AARM 13.1 (8.v, 8.w; 8.gg, 8.hh)
+>
+> Add independent and independent components, respectively.
+>
+> C.6
+>
+> Add pragmas Independent and Independent_Components. Independent
+> applies to components of record types; Independent_Components
+> applies to components of arrays or anonymous array objects.
+
+The pragmas make good sense indeed. And with the pragmas the whole
+business of trying to specify what is meant by a confirming rep
+clause disappears.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, May 21, 2006 12:25 AM
+
+...
+> What on earth is the semantic
+> definition of a confirming representation clause.
+
+It's in 13.1(18.2/2):
+
+A representation item that specifies an aspect of representation that would
+have been chosen in the absence of the representation item is said to be
+confirming.
+
+The recommended level of support 13.1(21.1/2) is that confirming items (if
+they can be written, see below) always be supported.
+
+Next question. ;-)
+
+> After all
+> there is nothing in the standard that prevents a compiler
+> from basing the representation of an item on the phases
+> of the moon, or the MD-5 checksum of the program (the latter
+> ensuring that the would-be default representation is changed
+> by adding "confirming rep clauses". Also it may simply not
+> be possible from a formal point of view to specify a confirming
+> rep clause, e.g. suppose that an array is by default stored
+> in some sparse hash table form, and only has a meaningful
+> component size if one is specified, or if the component size
+> is queried. etc etc.
+
+Recommended level of support is always implementation advice.
+
+In any case, we had this discussion right here on the ARG list back in
+February of 2006. Then, you said:
+
+> Indeed. I actually think that there should be a rule that the
+> compiled accept all confirming representation clauses, which
+> is not necessarily the case.
+
+To which it was pointed out that there indeed is such a rule in Ada 2005.
+
+Note that further discussion (and an AARM note) points out that it might not
+be possible to write a confirming rep. clause; the rule is intended to be
+read such that if you *can* write such a clause, then it must be accepted.
+
+It's also intended that a confirming representation item never have a
+semantic effect. We changed all of the chapter 13 rules to make that true;
+we missed this one on chapter 9. Since the "representation choosen by
+implementation by default" has to be independent anyway, this change can't
+have any semantic effect on a correct compiler. It just means that if you
+confirm a component size (for one example), you don't lose independence as a
+side-effect.
+
+Remember that independent components is the default; you don't need advice
+that the default remains true!
+
+The pragmas are needed so that you can force independence even when giving
+non-confirming representation items like Pack. (And if independence can't be
+maintained, then the program is illegal.)
+
+...
+> I do not see why convention should possibly affect independence
+
+Pascal brought that up. He suggested that "I don't understand why 9.10(1)
+doesn't mention pragma Convention. Consider an array of 4 characters. On
+an old Alpha, as you explained, it would have to be laid out with components
+occupying 32 bits. But if you put a pragma Convention (C) on the array, I
+would expect the components to use 8 bits. (I see that the C standard
+doesn't specify the size of char, but I am pretty sure that most of the C
+code out there
+assumes that it's 8 bits.)".
+
+Bibb is just trying to write the AI as the ARG agreed at the last meeting.
+
+Hope this helps.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, May 22, 2007 2:15 PM
+
+> Recommended level of support is always implementation advice.
+
+Not if Annex C is in effect
+>
+> In any case, we had this discussion right here on the ARG list back in
+> February of 2006. Then, you said:
+>
+>> Indeed. I actually think that there should be a rule that the
+>> compiled accept all confirming representation clauses, which
+>> is not necessarily the case.
+
+This is reasonable if there are no special semantics associated
+with this.
+
+> To which it was pointed out that there indeed is such a rule in Ada 2005.
+>
+> Note that further discussion (and an AARM note) points out that it might not
+> be possible to write a confirming rep. clause; the rule is intended to be
+> read such that if you *can* write such a clause, then it must be accepted.
+
+And that's fine
+
+> It's also intended that a confirming representation item never have a
+> semantic effect. We changed all of the chapter 13 rules to make that true;
+> we missed this one on chapter 9. Since the "representation choosen by
+> implementation by default" has to be independent anyway, this change can't
+> have any semantic effect on a correct compiler. It just means that if you
+> confirm a component size (for one example), you don't lose independence as a
+> side-effect.
+
+I find it awkward and confusing to have this rule. I think it better to
+rely on the new pragmas. After all we are changing the language right
+now. In Ada 2005, writing a confirming rep clause clearly does kill
+independence (even if this was not intended), so it has to be fixed,
+and the clean way of fixing it is with the pragmas in any case. It is
+a good thing to emphasize independence as a property rather than relying
+on the default behavior.
+
+It's a pity that we don't have a way of turning off independence by
+default. Probably implementations should add a configuration pragma
+that has this effect, relying on the new pragmas to add it back where
+needed (this would avoid having to unpack things just in case
+independence was required).
+
+Remember that in Ada 83, we just did not think this out properly at
+all (this was the huge change at the last minute in the printers
+proof that dealt with independence at all).
+
+The pragmas are a MUCH cleaner solution
+
+> Pascal brought that up. He suggested that "I don't understand why 9.10(1)
+> doesn't mention pragma Convention. Consider an array of 4 characters. On
+> an old Alpha, as you explained, it would have to be laid out with components
+> occupying 32 bits. But if you put a pragma Convention (C) on the array, I
+> would expect the components to use 8 bits. (I see that the C standard
+> doesn't specify the size of char, but I am pretty sure that most of the C
+> code out there
+> assumes that it's 8 bits.)".
+
+OK, that makes sense
+>
+> Bibb is just trying to write the AI as the ARG agreed at the last meeting.
+
+Well it's no big deal in fact, none of this independence stuff is
+anything any implementor gives a thought to (it just falls out :-))
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 22, 2007 3:02 PM
+
+> Well it's no big deal in fact, none of this independence stuff is
+> anything any implementor gives a thought to (it just falls out :-))
+
+I agree. And it is not really testable (a test which tries to generate a
+independence failure might very well work for many other reasons even if the
+independence is wrong). So, after choosing default representations
+appropriately, pretty much this is something worth worrying about only if
+there is a bug report from a customer (for instance, if a code generator
+gets too aggressive combining instructions).
****************************************************************
Questions? Ask the ACAA Technical Agent