volatile vs volatile_components

volatile vs volatile_components

[REH]

Is there a difference between defining an array with pragma volatile
vs volatile_components? The standard says that if the object is
volatile, its components are volatile. So, if the object is defined as
having volatile components, what does that say--if anything--about the
object as a whole?

Re: volatile vs volatile_components

[Adam Beneschan]

On Nov 5, 7:00 am, REH <spamj...@stny.rr.com> wrote:
> Is there a difference between defining an array with pragma volatile
> vs volatile_components? The standard says that if the object is
> volatile, its components are volatile. So, if the object is defined as
> having volatile components, what does that say--if anything--about the
> object as a whole?

Good question.  With Volatile_Components, the simple answer would be
that the array components are volatile but the array object as a whole
is not.  But after studying C.6, I have to admit that this doesn't
make much sense.  The purpose of Volatile is to make sure all reads
and writes of a volatile object are done exactly as the program tells
it to (no optimizing away of "redundant" loads, for instance); and if
you declare an array's subcomponents to be Volatile, you want reads
and writes of the components to occur just as the program says to do
them, and I'd think that reading and writing the entire array, since
it has volatile components, would mean that the array reads/writes
would also have to take place just like the program says, in order for
the desired effect to happen on the volatile components.  In other
words, I can't think of a single case where an operation on an array
that has Volatile_Components but not Volatile specified should behave
differently than the same operation on a Volatile array.

                                  -- Adam

Re: volatile vs volatile_components

[Dmitry A. Kazakov]

On Wed, 5 Nov 2008 17:21:25 -0800 (PST), Adam Beneschan wrote:

> I can't think of a single case where an operation on an array
> that has Volatile_Components but not Volatile specified should behave
> differently than the same operation on a Volatile array.

Packed; cached arrays? I would guess that when the array is volatile, but
its components are not, then subsequent reading two components occupying
the same memory location can be coalesced into one memory operation. It
would store things into; say; a register and the components would be
obtained from there. When the components are volatile the compiler must
read the memory twice.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: volatile vs volatile_components

[Stuart]

"REH" <spamjunk@stny.rr.com> wrote in message 
news:046f172d-90f7-4a23-a181-dd1461ebd94b@i18g2000prf.googlegroups.com...
> Is there a difference between defining an array with pragma volatile
> vs volatile_components? The standard says that if the object is
> volatile, its components are volatile. So, if the object is defined as
> having volatile components, what does that say--if anything--about the
> object as a whole?

As Adam Beneschan notes elsewhere it is an interesting question and the LRM 
does not seem to shed much light on it.

I was interested in what meaning might be attributed to a whole array 
assignment - does the LRM define a particular order in which the elements 
must be accessed.

Also in an assignment such as:
     A2 := A1;
should the whole of A1 be read (buffered) before the write to A2 commences 
(I think it should - but I am no language lawyer).

I tried the code below with a compiler here and it seemed to perform both 
whole array assignments as direct element by element copies (read then write 
of an element).  However, it also seemed to make a complete dogs dinner of 
the first case by effectively implementing:
        W := X;  -- copied element by element!!
        W := W;  -- copied element by element!!

Seemingly an explicit violation of the rules!!  A bug report methinks - but 
it would be interesting to be clear on exactly what the LRM requires it to 
do before submitting it.

package T is
   pragma Elaborate_Body;

   type Element is mod 2**16;

   type Index is range 1..100;

   type V_Array is array(Index) of Element;
   pragma volatile(V_Array);

   type VC_Array is array(Index) of Element;
   pragma volatile_components(VC_Array);

   W,X : V_Array;
   pragma volatile(W);
   pragma volatile(X);

   Y,Z : VC_Array;

   E : Element;
end T;

package body T is
begin
   -- Whole array assignments.
   W := X;
   Y := Z;

   -- Element by element assignments for comparison.
   for i in W'range loop
      X(i) := W(i);
   end loop;

   for i in Y'range loop
      Z(i) := Y(i);
   end loop;
end T;

-- 
Stuart 

Re: volatile vs volatile_components

[Adam Beneschan]

On Nov 6, 1:25 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Packed; cached arrays? I would guess that when the array is volatile, but
> its components are not

That's an impossible situation, by C.6(8): "Finally, if an object is
volatile, then so are all of its subcomponents".

                                  -- Adam

, then subsequent reading two components occupying
> the same memory location can be coalesced into one memory operation. It
> would store things into; say; a register and the components would be
> obtained from there. When the components are volatile the compiler must
> read the memory twice.