Pragma Volatile

Pragma Volatile

[Jon R. Harshaw]

OK. - Since I can't find a reference for this in my limited
documentation, what does "Pragma Volatile" do?  I'm guessing that it is
just available while the process that invokes it is up and running, but
that's just a WAG...

--
Jon.Harshaw@raytheon.com
Phone: (814)-278-2908
Bldg. 5, Cube 679

Re: Pragma Volatile

[David C. Hoos]

Pragma Volatile is defined in RM95 C.6

C.6 (16) says:
For a volatile object all reads and updates of the object as
a whole are performed directly to memory.

----- Original Message ----- 
From: "Jon R. Harshaw" <Jon.Harshaw@raytheon.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, September 25, 2001 9:07 AM
Subject: Pragma Volatile


> OK. - Since I can't find a reference for this in my limited
> documentation, what does "Pragma Volatile" do?  I'm guessing that it is
> just available while the process that invokes it is up and running, but
> that's just a WAG...
> 
> --
> Jon.Harshaw@raytheon.com
> Phone: (814)-278-2908
> Bldg. 5, Cube 679
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: Pragma Volatile

[Marin David Condic]

You apply it to an object (variable) to prevent the compiler from optimizing
the memory location away and/or keeping it in a register. This is useful for
embedded apps that need to make sure that when an object "X" is declared,
that it actually resides in memory somewhere because, for example, it may be
read/updated by other hardware/software.

This should be explained in the ARM somewhere - have you tried looking
around through that? If you don't have the ARM available, it does exist
on-line at http://www.adapower.org/

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jon R. Harshaw" <Jon.Harshaw@raytheon.com> wrote in message
news:3BB08F9C.BFB01047@raytheon.com...
> OK. - Since I can't find a reference for this in my limited
> documentation, what does "Pragma Volatile" do?  I'm guessing that it is
> just available while the process that invokes it is up and running, but
> that's just a WAG...
>

Re: Pragma Volatile

[Mark Johnson]

"Jon R. Harshaw" wrote:

> OK. - Since I can't find a reference for this in my limited
> documentation, what does "Pragma Volatile" do?  I'm guessing that it is
> just available while the process that invokes it is up and running, but
> that's just a WAG...

Hmm. Which "limited documentation" are you looking at.

A quick search of the web for pragma, volatile, and Ada find several good
references....
 - Ada 95 style guide,
http://www.cs.aston.ac.uk/~barnesa/ada_style/cover.html (look in section 6
on concurrency)
 - Ada 95 rationale,
http://lglwww.epfl.ch/docs/ada/rat95html-1.04/rat95-p3-c.html#5
and so on.

As others have noted, the Ada Reference Manual defines the term. Looking
in the bookcase on my right, I note that The Annotated ARM in section C.6
(para 20.a through 20.i) has a nice example describing how extra load /
extra store operations are not allowed & that loads and stores may not be
reordered.

A caution, after reading a number of articles on caches & memory
visibility, I am not so sure the compiler vendors are putting enough care
into enforcing the last restriction. In general, caches can reorder or
combine writes which could violate that restriction. If you use volatile
in conjunction w/ protected units and objects, you are probably OK. This
is really a system dependent problem & I would need a lot more information
about what you are trying to do [and why] to determine if you would have
this problem.
--Mark

Re: Pragma Volatile

[Tucker Taft]

Mark Johnson wrote:

> "Jon R. Harshaw" wrote:
>
> > OK. - Since I can't find a reference for this in my limited
> > documentation, what does "Pragma Volatile" do?  I'm guessing that it is
> > just available while the process that invokes it is up and running, but
> > that's just a WAG...

> ...

>
> A caution, after reading a number of articles on caches & memory
> visibility, I am not so sure the compiler vendors are putting enough care
> into enforcing the last restriction. In general, caches can reorder or
> combine writes which could violate that restriction. If you use volatile
> in conjunction w/ protected units and objects, you are probably OK. This
> is really a system dependent problem & I would need a lot more information
> about what you are trying to do [and why] to determine if you would have
> this problem.

The primary purpose of "volatile" is to warn the compiler that
the associated memory location might be read or updated
asynchonously by some other process or device.

There shouldn't be any problem if you are using this in a mono-processor.
On a multi-processor without synchronized caches, you can get into
trouble, but the onus is probably on the programmer to make sure
that variables shared between processors are placed in uncached
memory.  The compiler may not know enough about your
environment to arrange for that.

Certainly if the memory is shared with an I/O device, then it is
almost certainly uncached.

Another way to think about "volatile" is that you are asking the
compiler to not "cache" within registers the value of the memory
location, and instead always operate directly on the memory location.
In a multiprocessor environment, you would ideally like the compiler
to arrange for the memory not to be cached (in an unsynchronized
cache) by the hardware either, but as mentioned above, the compiler
may not have enought information or control over the hardware
environment to ensure that.


>
> --Mark

-Tucker Taft  stt@avercom.net

Re: Pragma Volatile

[minyard]

Tucker Taft <stt@avercom.net> writes:

> There shouldn't be any problem if you are using this in a mono-processor.
  (talking about volatiles not being important on uniprocessors).

Note that this isn't true at all.  Multiprocessors require special
instructions for syncronization, but volatile is just as important on
a uniprocessor as a multiprocessor.  You use it when talking to device
registers (which are changed asyncronously or have side effects) or in
variables shared between tasks (because you can't necessarily
guarantee when tasks switch).  You are telling the compiler that the
variable has side-effects that it doesn't know about.  I assume
Mr. Taft know this but was trying to make another point.

Note that the rest of what was said was true; I am just addressing
this one point.

Another way to think about volatiles is that they guarantee that any
operation done on the variable is actually done.  For instance:

  A : Integer;
  .
  .
  .
  A := 1;
  while (A /= 0) loop
     delay 1.0;
  end loop;

A compiler would look at this and say "Hey, A doesn't change in the
loop, and A is set right before, so this just really just an infinite
loop", even if some other task changes A.  Setting A volatile
guarantees that every time you reference A and compare, it actually
get's referenced and compared.

Also, consider a register to reset a device, where you write a 0 then
a 1 to reset it.

  B : Register_Access;

  B.all := 0;
  B.all := 1;

Again, a compiler can say, "Hey, we can just ignore the first
operation, because it doesn't have any effect", from the compiler's
point of view.  But setting B volatile guarantees that both operations
get done.  Actually, I'm not sure of the syntax here, because what B
references is volatile, not B itself.  So I'm guessing you would have

  type Register_Access is access all Integer;
  pragma Volatile(Register_Access);

Instead of making B volatile.  This is just like the "C" language,
where the location of the "volatile" keyword is very critical to what
gets set volatile.

-Corey

Re: Pragma Volatile

[Jeffrey Carter]

minyard@acm.org wrote:
> 
> Tucker Taft <stt@avercom.net> writes:
> 
> > There shouldn't be any problem if you are using this in a mono-processor.
>   (talking about volatiles not being important on uniprocessors).

From my reading of Taft's post, he did not say that pragma Volatile was
unimportant on uniprocessors. He said that achieving the desired
volatility is not a problem on uniprocessors; that you can count on the
compiler locating an object at an appropriate location if pragma
Volatile applies to it.

> Also, consider a register to reset a device, where you write a 0 then
> a 1 to reset it.
> 
>   B : Register_Access;
> 
>   B.all := 0;
>   B.all := 1;
> 
> Again, a compiler can say, "Hey, we can just ignore the first
> operation, because it doesn't have any effect", from the compiler's
> point of view.  But setting B volatile guarantees that both operations
> get done.  Actually, I'm not sure of the syntax here, because what B
> references is volatile, not B itself.  So I'm guessing you would have
> 
>   type Register_Access is access all Integer;
>   pragma Volatile(Register_Access);

If a register is an Integer, I would generally do

B : Integer;
for B'Address use Register_Location;
pragma Volatile (B);
...
B := 0;
B := 1;

But then, I don't have the C pointer fixation.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail

Re: Pragma Volatile

[DuckE]

<minyard@acm.org> wrote in message news:m3ofnt26xq.fsf@wf-rch.cirr.com...
> Tucker Taft <stt@avercom.net> writes:
>
> > There shouldn't be any problem if you are using this in a
mono-processor.
>   (talking about volatiles not being important on uniprocessors).
>
> Note that this isn't true at all.  Multiprocessors require special
> instructions for syncronization, but volatile is just as important on
> a uniprocessor as a multiprocessor

Go re-read Tuckers' post.

Keep in mind that when working on a multiprocessor system, the compiler
doesn't have any control over cache consistancy.

SteveD

Re: Pragma Volatile

[Robert Dewar]

minyard@acm.org wrote in message news:<m3ofnt26xq.fsf@wf-rch.cirr.com>...
> Tucker Taft <stt@avercom.net> writes:
>  I assume
> Mr. Taft know this but was trying to make another point.

Yes, indeed, reread his post more carefully, he was quite
clear and correct in what he said, which was that reordering of memory
accesses is not an issue on a single
processor. That is the only point he was addressing.

He was of COURSE not saying that Volatile is not significant  on a
single processor.

Hint: if you think Tuck has said something that is
completely wrong, you are almost certainly missing 
something :-)

Re: Pragma Volatile

[Robert Dewar]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3BB64B13.81AFFB4D@acm.org>...
> If a register is an Integer, I would generally do
> 
> B : Integer;
> for B'Address use Register_Location;
> pragma Volatile (B);
> ...
> B := 0;
> B := 1;
> 
> But then, I don't have the C pointer fixation.


Be very careful about assumptions here. Suppose that
B is a 32-bit word, then there is nothing in the language
that says that

  B := 0;

has to generate a 32-bit store, it would be perfectly 
valid if the compiler generated a call to bcopy that
moved four bytes independently (inefficient, but not
incorrect).

I often find people making this kind of assumption, and
in the case of reads I saw one awful bug caused by this:

    
    type R is array (natural range <>) of Boolean;
    pragma Pack (R);
 
    Register : R (1 .. 32);
    for Register'Address use ...

    ...

    B := Register (3);

one compiler generated a word load, and extracted bit 3.
another compiler generated a byte load, and extracted bit 3 from the
byte.

Both code sequences are perfectly valid, and just as
efficient as one another. But the hardware had been
build to require word loads, and byte loads were don't
care and put the hardware into some obscure state.

The "fix" was to use a constrained base type (this was
the only use of the type anyway), and then both compilers
generated the 32-bit word load.

But of course the real bug is in the implicit assumption
in the code.

Yes, it is very neat to use the address clause for memory
mapped I/O devices, but it is definitely cheating in that
it is making unwarranted assumptions about the exact code
sequences generated. 

Technically such code is quite wrong, and should be replaced by
machine code inserts. But that is heavy
in practice. At the very least, document assumptions
like this ferociously, and isolate them in special
packages known to need looking at when porting. 

Robert Dewar
Ada Core Technologies

Re: Pragma Volatile

[minyard]

You are, of course, correct.  I didn't read the context, I just read
the paragraph that he wrote (and not what was he was responding to)
and misunderstood.  I apologise to Mr. Taft.

-Corey

dewar@gnat.com (Robert Dewar) writes:
> minyard@acm.org wrote in message news:<m3ofnt26xq.fsf@wf-rch.cirr.com>...
> > Tucker Taft <stt@avercom.net> writes:
> >  I assume
> > Mr. Taft know this but was trying to make another point.
> 
> Yes, indeed, reread his post more carefully, he was quite
> clear and correct in what he said, which was that reordering of memory
> accesses is not an issue on a single
> processor. That is the only point he was addressing.
> 
> He was of COURSE not saying that Volatile is not significant  on a
> single processor.
> 
> Hint: if you think Tuck has said something that is
> completely wrong, you are almost certainly missing 
> something :-)

Re: Pragma Volatile

[Jeffrey Carter]

Robert Dewar wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3BB64B13.81AFFB4D@acm.org>...
> > If a register is an Integer, I would generally do
> >
> > B : Integer;
> > for B'Address use Register_Location;
> > pragma Volatile (B);
> > ...
> > B := 0;
> > B := 1;
> >
> > But then, I don't have the C pointer fixation.
> 
> Be very careful about assumptions here. Suppose that
> B is a 32-bit word, then there is nothing in the language
> that says that
> 
>   B := 0;
> 
> has to generate a 32-bit store, it would be perfectly
> valid if the compiler generated a call to bcopy that
> moved four bytes independently (inefficient, but not
> incorrect).

Thanks again to Robert Dewar for pointing out implicit assumptions.

I was actually responding to Corey Minyard's implicit assumption that a
pointer was needed to access a memory-mapped hardware register.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail

Re: Pragma Volatile

[minyard]

Jeffrey Carter <jrcarter@acm.org> writes:
> 
> Thanks again to Robert Dewar for pointing out implicit assumptions.
> 
> I was actually responding to Corey Minyard's implicit assumption that a
> pointer was needed to access a memory-mapped hardware register.

Yes, I am a C programmer (the cursed language).  I am coming back to
Ada after not using it for a while, and I had forgotten you could
assign addresses that way.  I haven't gotten that far back into Norm
Cohen's book :-).  But even if I had remembered, I would have made the
same example, because part of the point was that you need to be
careful what you make volatile.  If you make the wrong thing volatile,
it doesn't help at all, and it's easy to make the mistake.  Not as
easy as in C, though.

-Corey

Re: Pragma Volatile

[AG]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0109300510.71255128@posting.google.com...

>
> I often find people making this kind of assumption, and
> in the case of reads I saw one awful bug caused by this:
>
>
>     type R is array (natural range <>) of Boolean;
>     pragma Pack (R);
>
>     Register : R (1 .. 32);
>     for Register'Address use ...
>
>     ...
>
>     B := Register (3);
>
> one compiler generated a word load, and extracted bit 3.
> another compiler generated a byte load, and extracted bit 3 from the
> byte.
>
> Both code sequences are perfectly valid, and just as
> efficient as one another. But the hardware had been
> build to require word loads, and byte loads were don't
> care and put the hardware into some obscure state.
>

Isn't it true that a compiler that puts it's target machine into
some obscure state can't be called perfectly valid? After all,
it is the job of the compiler to either produce a valid code or
reject what isn't possible. Can you really call a code sequence
(generated by a compiler with no control by the programmer)
"perfectly valid" if it sends the target machine from here to
"some obscure state"?

> But of course the real bug is in the implicit assumption
> in the code.

Well, that may be a bug in the assumptions in the code, but
it also looks like a compiler bug in so far that it accepted and
(mis)implemented those assumptions.

Re: Pragma Volatile

[Jeff Creem]

"AG" <ang@xtra.co.nz> wrote in message
news:fVfu7.147$jc1.20018@news.xtra.co.nz...
>
> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0109300510.71255128@posting.google.com...
>
> >
> > I often find people making this kind of assumption, and
> > in the case of reads I saw one awful bug caused by this:
> >
> >
> >     type R is array (natural range <>) of Boolean;
> >     pragma Pack (R);
> >
> >     Register : R (1 .. 32);
> >     for Register'Address use ...
> >
> >     ...
> >
> >     B := Register (3);
> >
> > one compiler generated a word load, and extracted bit 3.
> > another compiler generated a byte load, and extracted bit 3 from the
> > byte.
> >
> > Both code sequences are perfectly valid, and just as
> > efficient as one another. But the hardware had been
> > build to require word loads, and byte loads were don't
> > care and put the hardware into some obscure state.
> >
>
> Isn't it true that a compiler that puts it's target machine into
> some obscure state can't be called perfectly valid? After all,
> it is the job of the compiler to either produce a valid code or
> reject what isn't possible. Can you really call a code sequence
> (generated by a compiler with no control by the programmer)
> "perfectly valid" if it sends the target machine from here to
> "some obscure state"?
>
> > But of course the real bug is in the implicit assumption
> > in the code.
>
> Well, that may be a bug in the assumptions in the code, but
> it also looks like a compiler bug in so far that it accepted and
> (mis)implemented those assumptions.
>
>
>

No it is not a compiler bug for cases like this. It is not that the compiler
puts
the target into an obscure state. Cases like this arise when you have some
specific hardware that you are address mapping to where that hardware does
not
allow certain addressing modes that ARE perfectly valid for the architecture
of the processor.

One could only say this is a compiler problem if the compiler was some
strange compiler that
was build to know about the specific hardware that you are interfacing to.
(Like some magic gcc build built with)
./configure --target=power-pc-with-some-custom-hardware-at-address-0x404040-
to0x505055-that-requires-longword-access-even-though-this-processor-is-byte-
addressable

(sorry for the 80 col violation but I was trying to get the point across).


To put it another way, the code that the compiler generated would be fine if
the address of
the variable Register was in normal system RAM but falls apart when the
address is mapped
to some hardware that only allows longword (or some other specific) access.