CVS difference for ais/ai-00259.txt

--- ais/ai-00259.txt	2002/04/26 20:15:17	1.3
+++ ais/ai-00259.txt	2003/01/16 02:15:26	1.4
@@ -1,18 +1,17 @@
-!standard  C.6 (20)                                    02-04-19  AI95-00259/01
+!standard  C.6 (16)                                    03-01-15  AI95-00259/03
 !standard  C.6 (21)
-!class ramification 01-02-12
+!class binding interpretation 03-01-10
 !status work item 02-04-19
 !status received 01-02-12
 !qualifier Omission
 !priority Medium
 !difficulty Medium
-!subject Can accesses to atomic objects be combined?
+!subject Can accesses to volatile objects be combined?
 
 !summary
 
-Implementation advice is added to encourage implementations to implement
-accesses to atomic operations as single instructions which only access the
-particular bits in question.
+Implementations may not combine accesses to volatile objects with accesses
+to other objects.
 
 !question
 
@@ -27,49 +26,82 @@
    Y := ...;
 
 Can the memory writes to atomic objects X and Y be combined into a single
-store operation?
+store operation? (No.)
 
-!response
+!recommendation
 
-Atomic objects are intended (among other uses) to support communication
+(See summary.)
+
+!wording
+
+(See corrigendum.)
+
+!discussion
+
+Volatile objects are intended (among other uses) to support communication
 between Ada programs and non-Ada software or hardware devices. Some hardware
 devices require access in particular ways. For example, some devices must be
 accessed with a byte operation; a word operation does not work.
 
-If memory reads and writes of atomic objects are combined into a single
+If memory reads and writes of volatile objects are combined into a single
 operation, it is not possible to write Ada code which can safely access such
 a device. Even if it works on the current version of a compiler, a newer
 compiler with better optimizations may break the program.
+
+Therefore, we extend the definition of volatile to insure that accesses are
+not combined. Since Atomic implies volatile, this means that the writes to
+X and Y in the question cannot be combined.
+
+But this does not go far enough. We cannot talk about bits that do not belong
+to any Ada object at the Ada semantic level. What we really want is to say that
+accesses to a volatile object can access only the bits belonging to that
+object, and no others. That requires implementation advice.
+
+We have to be careful, however, as Volatile may be applied to any Ada object.
+If the object is not an even multiple of the Storage_Unit size, it probably
+is not possible to access it without accessing other bits. Since subcomponents
+of a Volatile object are also Volatile, single components are going to
+frequently occur. We don't want to adopt advice that is impossible to follow,
+thus we limit the rule to objects that have a size which is a multiple of
+System.Storage_Unit.
+
+An atomic object is used when the object must be accessed indivisibly.
+Generally, that should be done with a single instruction, so we've added
+implementation advice to say that as well.
+
+Note that an implementation that does not follow implementation advice is
+required to document that, so users will know if an implementation is suitable
+for accessing hardware directly.
 
-However, it is not possible to specify this as a language requirement, as it
-is not possible to determine the difference between a combined write and a
-pair of writes at the level of Ada semantics. Moreover, any attempt to do so
-uses machine level terms not part of the Ada model.
-
-Therefore, we adopt implementation advice to do the correct thing. As with
-all implementation advice, an implementation must document when it is not
-followed. Thus, users can determine whether or not their implementation
-will handle Atomic objects as intended.
+!corrigendum C.06(16)
 
+@drepl
+For a volatile object all reads and updates of the object as a whole are
+performed directly to memory.
+@dby
+For a volatile object all reads and updates of the object as a whole are
+performed directly to memory, and shall not be combined with reads or updates
+of other objects.
+
 !corrigendum C.06(21)
 
 @dinsa
 If a pragma Pack applies to a type any of whose subcomponents are atomic, the
 implementation shall not pack the atomic subcomponents more tightly than that
 for which it can support indivisible reads and updates.
-@dinst
-@s8<@i<Implementation Advice>>@hr
+@dinss
+@i<@s8<Implementation Advice>>
+A load or store of a volatile object whose size is a multiple of
+System.Storage_Unit should be implemented by accessing exactly the bits of the
+object and no others.
 
-A load or store of an atomic object should, where possible,
-be implemented by a single load or store instruction which
-accesses exactly the bits of the object and no others. The
-implementation should document those instances in which
-it is not possible to follow this advice.
+A load or store of an atomic object should, where possible, be implemented
+by a single load or store instruction.
 
 !ACATS test
 
-This is implementation advice which is not testable without examining the
-generated code (which is prohibited by the ACATS charter).
+This is not testable without examining the generated code (which is prohibited
+by the ACATS charter).
 
 !appendix
 
@@ -803,3 +835,112 @@
 Fair enough.
 
 ***********************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 10, 2003  9:34 PM
+
+I've been working on my homework. At the bottom of this note, you'll find my
+rewrite of AI-259 [this was version /02 - ED], based on the minutes of the
+Bedford meeting.
+
+I have two problems with the revised AI:
+
+1) I have no idea why we've extended this to cover volatile. The minutes are no
+   help (not surprisingly). I vaguely recall Mike Yoder saying something about
+   multiprocessors. I need a good example of why combining writes for a
+   volatile object is a bad thing (beyond people using the pragmas for purposes
+   for which they were not intended).
+
+2) I don't think the fix solves the original problem. The *question* is
+   answered, but the core e-mail point was not. To steal an a question and
+   example from Robert Dewar: Is this or is this not a recommended style of Ada
+   programming:
+
+    X : Byte;
+    for X'Address use .. some mem mapped address
+    for X'Size use 8;
+    pragma Atomic (X);
+
+where the programmer needs only byte read/write instructions to be used to
+access X.
+
+For this to work, the object and *only* the object in question can be accessed.
+The proposed rule:
+
+"For a volatile object all reads and updates of the object as a whole are
+performed directly to memory, and shall not be combined with reads or updates
+of other objects."
+
+That would prevent the compiler from writing other Ada objects. But it doesn't
+say anything about bits that aren't part of any (Ada) object. The compiler
+still could write to unused bits near X if it wanted to. But of course that
+doesn't have the right effect.
+
+We've also lost the value of the documentation that came with the (rejected)
+Implementation Advice. The IA suggested the use of a single instruction for
+accesses to Atomic objects, and required documentation when that wasn't
+possible to meet. While I can't see a single byte access taking multiple
+instructions, it certainly is possible with word registers. In the similar
+example:
+
+    X : Word;
+    for X'Address use .. some mem mapped address
+    for X'Size use 16;
+    pragma Atomic (X);
+
+we want to discourage using a pair of byte writes here.
+
+So I think that we still need the implementation advice, for Atomic only:
+"A load or store of an atomic object should, where possible, be implemented
+by a single load or store instruction which accesses exactly the bits of the
+object and no others. The implementation should document those instances in
+which it is not possible to follow this advice."
+
+***********************************************************
+
+From: Tucker Taft
+Sent: Saturday, January 11, 2003  9:04 AM
+
+I agree you should indicate that any memory outside of
+the volatile object (including memory that is part of other
+objects) should not be read or written.
+
+I agree that we should keep the advice about single
+instructions for atomic objects.
+
+As far as why extend this to "volatile" -- the reasoning
+I believe was that everyone agreed that volatile was
+useful for communicating with memory-mapped I/O registers,
+whereas there were a number of people who felt "atomic"
+was not for that purpose (though the Ada 9X design team
+would not have agreed with them).  It seemed less confusing
+for these people to associate these rules with volatile
+rather than with atomic.  And since volatile covers atomic,
+those who preferred the focus on atomic didn't think it
+was worth arguing about further ;-).
+
+***********************************************************
+
+From: Robert Dewar
+Sent: Sunday, January 12, 2003  7:32 PM
+
+> "For a volatile object all reads and updates of the object as a whole are
+> performed directly to memory, and shall not be combined with reads or
+> updates of other objects."
+
+I think this should be implementation advice. It is really impossible to
+interpret the above sentence formally. What does it mean "directly to
+memory", what does "combine" mean. The RM is simply not in the business
+of specifying machine language translation sequences, but rather semantic
+effects.
+
+***********************************************************
+
+From: Robert Dewar
+Sent: Sunday, January 12, 2003  7:34 PM
+
+Just to be clear here, I think that IA would be much stronger in practice
+than junk meaningless non-formally interpretable requirements.
+
+***********************************************************
+