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

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

--- ai05s/ai05-0117-1.txt	2010/02/19 07:17:41	1.3
+++ ai05s/ai05-0117-1.txt	2010/06/13 01:30:12	1.4
@@ -1,4 +1,4 @@
-!standard  C.6(23)                                   08-10-16    AI05-0117-1/00
+!standard  C.6(23)                                   10-06-04    AI05-0117-1/01
 !class Amendment 08-10-16
 !status work item 08-10-16
 !status received 08-07-29
@@ -8,35 +8,102 @@
 
 !summary
 
-(See proposal.)
+A new pragma is defined that controls the ordering of access to
+shared variables.
 
 !problem
 
 Some Lock-free and wait-free algorithms rely on a specific order of
 loads and stores of some variables. However, modern multi-core
-architectures do not guarantee that between processors unless
+architectures do not guarantee this ordering between processors unless
 special instructions are used. Ada should require some behavior
 which will allow these algorithms to be programmed in a straightforward
 manner.
 
-More generally, the language ought to consider additional ways to
-support multi-core architectures.
-
 !proposal
 
-** TBD **
+Add a new representation pragma that controls the ordering of access to
+shared variables. The new control would be similar to pragma Volatile
+without the need to perform read and updates on the object directly
+to memory.
 
 !wording
+
+Add a new clause:
+
+D.16.3 Shared Variable Control for Multiprocessor Implementation
+
+This clause specifies a representation pragma that controls the use of
+shared variables on multiprocessors.
+
+Syntax
+
+The form of a pragma CPU is as follows:
+
+pragma Coherent(local_name);
+
+A coherent type is one to which a pragma coherent applies. A coherent
+object is one to which a pragma coherent applies.
+
+Name Resolution Rules
+The local_name shall resolve to denote either an object_declaration, a
+non-inherited component_declaration, or a full_type_declaration.
+
+Legality Rules
+If a coherent object is passed as a parameter ... [C.6(12)]
+
+Static Semantics
+The pragma is a representation pragma (see 13.1).
+
+Dynamic Semantics
+Two actions are sequential (see 9.10) if each is the read or update
+of the same coherent object.
+
+[C.6(18-19)]
+
+Implementation Requirement
+The external effect of a program (see 1.1.3) is defined to include each read and
+update of a coherent object. Reads and updates of two different coherent
+objects in the same task are in the order specified by the program.
+
+--
+
+Add to 9.10(15) Coherent and see D.16.3.
 
-** TBD **
+--
+Add after (or as part of) 1.1.3(13):
 
+Any read or update of a coherent object (see D.16.3);
+
 !discussion
 
-** TBD **
+See appendix
 
 !example
 
+The following will ensure that task 2 does get the value 42.
+
+Data : Integer;
+pragma Coherent (Data);
+
+Flag : Boolean := False;
+pragma Coherent (Flag);
+
+
+in task 1:
+
+ Data := 42;
+ Flag := True;
+
 
+in task 2:
+
+ loop
+   exit when Flag;
+ end loop;
+ Copy := Data;
+
+
 !ACATS test
 
 
@@ -248,6 +315,347 @@
 This is not recommended as there is no single set of operations; hardware
 solutions differ. Other languages provide various forms of volatile (eg C, C++
 and Java).
+
+****************************************************************
+
+From: Alan Burns
+Date: Friday, April 23, 2010  2:37 AM
+
+A question about where to place the definition of the pragma.
+
+To recap - the point of this pragma is to ensure that the compiler/processor
+does not reorder memory assesses (so that various useful algorithms will work on
+multiprocessors).
+
+This seems easy to ensure by defining any read or write on a coherent object to
+be an 'external effect' (1.1.3(13)). This with 1.1.3(15) about ordering would
+seem to be sufficient.
+
+my reading of this is that if the program needs to ensure that:
+write(x);
+write(y);
+does indeed occur in that order then BOTH x and y would need to be defined as
+coherent - agree? or is it sufficient just to define x as coherent?
+
+This pragma could be defined in C.6 with atomic and volatile, but to give it
+equal status would require considerable rewriting. But as coherence is only
+really needed with multiprocessor systems then I feel it would be easier to
+define it in the new Multiprocessor section of the real-time annex - agree?
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Date: Friday, April 23, 2010  2:53 AM
+
+> This seems easy to ensure by defining any read or write on a coherent
+> object to be an 'external effect' (1.1.3(13)).
+
+Why isn't volatile sufficient (it is an external effect for volatile)?
+
+****************************************************************
+
+From: Alan Burns
+Date: Friday, April 23, 2010  4:25 AM
+
+This was discussed at last meeting - volatile is too strong, yes it gives what
+is required, but it also requires all writes to be direct to memory (effectively
+bypassing cache). This is not necessary as cache coherence is fine, the key is
+that the complier does not reorder. See discussion in AI
+
+****************************************************************
+
+From: Robert Dewar
+Date: Friday, April 23, 2010  11:49 AM
+
+> A question about where to place the definition of the pragma.
+
+I definitely think this pragma must be optional, i.e. the compiler is free to
+reject it if it cannot be guaranteed, like pragma Atomic. I am pretty sure we
+would just reject it all the time. Because we have no way of constraining the
+code generator in this respect.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Friday, April 23, 2010  11:50 AM
+
+> This was discussed at last meeting - volatile is too strong, yes it
+> gives what is required, but it also requires all writes to be direct
+> to memory (effectively bypassing cache). This is not necessary as
+> cache coherence is fine, the key is that the complier does not
+> reorder. See discussion
+
+Ah, OK, so in fact this is easy to implement, we just treat it as Volatile, so I
+withdraw my objection.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, April 23, 2010  1:01 PM
+
+Right, that works, but as we're determined, that requires generating memory
+barriers in many places for multicore/multiprocessor architectures. Which is a
+real performance drag.
+
+I don't know about GNAT specifically, but I would guess that what the majority
+of compilers have been calling "Volatile" is really "Coherent". So I think you
+are right that Coherent can be implemented as (current) Volatile, but Volatile
+will often need more work to be implemented correctly. Of course, that depends
+on whether customers care; I don't think there is any practical way for portable
+tests (like the ACATS) to verify if this is done properly -- it requires
+examining the emitted code for each architecture. So customer demand will be the
+only incentive to implement Volatile correctly.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Saturday, April 24, 2010  11:47 AM
+
+To me, if the Ada notion of volatile does not match C's notion of volatile then
+
+a) it is junk
+
+b) GNAT will not implement it, regardless of customer demand!
+
+****************************************************************
+
+From: Bob Duff
+Date: Friday, April 23, 2010  9:09 PM
+
+I'm not a C language lawyer, but my impression is that nobody really understands
+precisely what "volatile" in C means. And I've heard that the committee
+deliberately left it vague, so implementations can do more-or-less what they
+like.
+
+I also read a paper where they tested various compilers, and found that nobody
+implements volatile in C properly (for whatever semantics the authors of that
+paper think is "proper").
+
+I had a conversation with somebody who was griping about the lack of clarity in
+the C standard w.r.t. volatile, and I pointing him to the Ada definition, and I
+think he said the Ada version was much superior.
+
+The C definition has something to do with setjump/longjump (in part).  And C
+doesn't have threads.
+
+This is all rumor and hearsay -- sorry.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Sunday, April 25, 2010  4:56 AM
+
+In practice GNAT does (and will for ever) give the same semantics for Volatile
+that gcc does. People use volatile all the time both in GNAT and GNU C, without
+any problems or reports of difficulty for 15 years, so I don't see that there is
+a problem here that needs solving, or that a more precise solution will be of
+any use.
+
+I am not aware at all of the confusion over volatile of which Bob Duff presents
+rumor and hearsay :-)
+
+However, I am not concerned too much, sonds like 10 mins work to add pragma
+Coherent and make it mean the same as Volatile.
+
+****************************************************************
+
+From: Bob Duff
+Date: Sunday, April 25, 2010  8:14 AM
+
+> I am not aware at all of the confusion over volatile of which Bob Duff
+> presents rumor and hearsay :-)
+
+The paper I mentioned is here:
+
+    http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf
+
+    "Volatiles Are Miscompiled, and What to Do about It"
+
+The rest of what I said remains rumor and hearsay.
+
+****************************************************************
+
+From: Alan Burns
+Date: Monday, April 26, 2010  5:21 AM
+
+> However, I am not concerned too much, sonds like 10 mins work to add
+> pragma Coherent and make it mean the same as Volatile.
+
+Just to recap - leaving aside 'atomic' there are two properties that 'volatile'
+is aimed at:
+
+1 - all rights/read go directly to the memory location - needed (only) when the
+memory location is a register for some external device.
+
+2 - control reordering (bound what reordering can take place due to compiler or
+processor behaviour).
+
+Not sure what GNAT does, but C seems to be aimed more at the second property.
+Ada's 'volatile' is concerned with the first property. So GNAT C may not give
+Ada's semantics - it will ensure no reordering but will leave it to memory
+manager to decide when, for example, values can just stay in cache.
+
+With multicore there is a real need to get control over reordering. Hence the
+introduction, in Ada, of Coherent - this would be easy to implement as it just
+requires the insertion of calls to a memory barrier which all such hardware
+seems to support.
+
+So I would guess that GNAT 'Volatile' implements Ada's new 'Coherent'.
+But this leaves open the question of how to get Ada's Volatile.
+
+I'm told that Java's volatile is defined in terms of Lamport's 'happens before'
+operation - hence it is concerned with ordering.
+
+PS the discussions did not however tell me where to define Coherent?
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, April 26, 2010  12:01 PM
+
+> 1 - all rights/read go directly to the memory location - needed (only)
+> when the memory location is a register for some external device.
+
+it is completely bogus to use pragma Volatile for this purpose, since in
+practice you will be making the non-portable assumption that a load or store
+uses a single appropriate machine instruction. Even the use of Atomic is dubious
+for this purpose! Device registers need to be accessed with very specific
+instructions. The ONLY legitimate way to ensure this is to write the appropriate
+ASM inserts. In practice Atomic may work fine for most cases, but I would NEVER
+use Volatile for this purpose.
+
+For example, if you have a 32-bit hardware register, and you set one bit, then
+several sequences of instructions are possible on a 386 (use bit instructions,
+use load/store, load/store byte rather than word etc). The use of Atomic pretty
+much guarantees a 32-bit read followed by a 32-bit write. If that's what you
+want it will probably work, but you cannot guarantee this from the RM. If you
+use Volatile, all bets are off as to the exact instructions generated.
+
+> 2 - control reordering (bound what reordering can take place due to
+> compiler or processor behaviour).
+
+Actually one of the most common uses of Volatile is to make sure that two
+independent tasks correctly access a common version without making private
+copies, e.g. a circular buffer where the input and output pointers are atomic,
+and the actual buffer contents is volatile.
+
+> Not sure what GNAT does, but C seems to be aimed more at the second
+> property. Ada's 'volatile' is concerned with the first property. So
+> GNAT C may not give Ada's semantics - it will ensure no reordering but
+> will leave it to memory manager to decide when, for example, values
+> can just stay in cache.
+
+As I said, to me if Volatile in Ada does not do what Volatile in C does, then it
+is confusing and useless.
+
+> With multicore there is a real need to get control over reordering.
+> Hence the
+> introduction, in Ada, of Coherent - this would be easy to implement as
+> it just requires the insertion of calls to a memory barrier which all
+> such hardware seems to support.
+
+Please do not assume that "instructions available on hardware" = "easy to
+implement". This equation is simply false in large modern compiler systems.
+
+> So I would guess that GNAT 'Volatile' implements Ada's new 'Coherent'.
+> But this leaves open the question of how to get Ada's Volatile.
+
+If Volatile is supposed to mean something different from Volatile in C, then I
+would say, you can't expect to "get" it at all. As I noted before, we never had
+a customer query or complaint in this area for the entire history of GNAT.
+
+> PS the discussions did not however tell me where to define Coherent?
+
+Since it's virtually the same issue as Volatile, I would put it in the same
+place.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, April 26, 2010  12:22 PM
+
+>> 1 - all rights/read go directly to the memory location - needed
+>> (only) when the memory location is a register for some external device.
+>
+> it is completely bogus to use pragma Volatile for this purpose, since
+> in practice you will be making the non-portable assumption that a load
+> or store uses a single appropriate machine instruction. Even the use
+> of Atomic is dubious for this purpose! Device registers need to be
+> accessed with very specific instructions. The ONLY legitimate way to
+> ensure this is to write the appropriate ASM inserts. In practice
+> Atomic may work fine for most cases, but I would NEVER use Volatile
+> for this purpose.
+
+I agree.  You generally need to use pragma Atomic if you want to guarantee a
+single instruction.  Volatile operations are allowed to result in multiple
+instructions.
+
+> For example, if you have a 32-bit hardware register, and you set one
+> bit, then several sequences of instructions are possible on a 386 (use
+> bit instructions, use load/store, load/store byte rather than word
+> etc). The use of Atomic pretty much guarantees a 32-bit read followed
+> by a 32-bit write. If that's what you want it will probably work, but
+> you cannot guarantee this from the RM. If you use Volatile, all bets
+> are off as to the exact instructions generated...
+
+I don't happen to agree that it is always necessary to use special instructions.
+A lot of device drivers have been written in the "Unix" era without ever using
+assembler. I suppose some of these depended on the "|=" C operator, so Ada comes
+up short there...
+
+Of course if the device is not memory mapped, but instead uses some kind of
+built-in "port," then you clearly need to resort to a special "intrinsic"
+operation.
+
+****************************************************************
+
+From: Bob Duff
+Date: Monday, April 26, 2010  12:48 PM
+
+> As I said, to me if Volatile in Ada does not do what Volatile in C
+> does, then it is confusing and useless.
+
+I think you mean that if Volatile in GNAT does not do what Volatile in gcc C
+does, then it is confusing and useless.  Because last time I looked at this part
+of the C standard it was confusing and useless, but that doesn't mean a
+particular C compiler can't do something useful.
+
+Anyway, why are we adding a new feature, if in practice it will be implemented
+the same as Volatile?
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, April 26, 2010  1:01 PM
+
+> I think you mean that if Volatile in GNAT does not do what Volatile in
+> gcc C does, then it is confusing and useless.  Because last time I
+> looked at this part of the C standard it was confusing and useless,
+> but that doesn't mean a particular C compiler can't do something
+> useful.
+
+Whether C volatile in the standard does anything useful, I have no idea.
+But C volatile in practice is very useful, and works fine, and Ada need do no
+better (in fact Ada already does better, from having Atomic -- a typical
+implementation in C gets around this by treating volatile the same as atomic in
+Ada if the type is suitable for that purpose (that of course is implementation
+dependent, as it is in Ada).
+
+> Anyway, why are we adding a new feature, if in practice it will be
+> implemented the same as Volatile?
+
+indeed.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, April 26, 2010  1:13 PM
+
+In practice, volatile works fine for mono-processors.
+As we move toward multicore/multi-processors being the norm, volatile will
+probably be insufficient.  I can believe GNAT will necessarily wait until
+something akin to Coherent is handled by the GCC back end, but that doesn't mean
+the distinction isn't important in the timeframe of Ada 2012.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent