* Pragma Volatile @ 2001-09-25 14:07 Jon R. Harshaw 2001-09-25 14:23 ` David C. Hoos ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Jon R. Harshaw @ 2001-09-25 14:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-25 14:07 Pragma Volatile Jon R. Harshaw @ 2001-09-25 14:23 ` David C. Hoos 2001-09-25 14:38 ` Marin David Condic 2001-09-25 23:03 ` Mark Johnson 2 siblings, 0 replies; 15+ messages in thread From: David C. Hoos @ 2001-09-25 14:23 UTC (permalink / raw) To: comp.lang.ada; +Cc: Jon.Harshaw 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-25 14:07 Pragma Volatile Jon R. Harshaw 2001-09-25 14:23 ` David C. Hoos @ 2001-09-25 14:38 ` Marin David Condic 2001-09-25 23:03 ` Mark Johnson 2 siblings, 0 replies; 15+ messages in thread From: Marin David Condic @ 2001-09-25 14:38 UTC (permalink / raw) 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... > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-25 14:07 Pragma Volatile Jon R. Harshaw 2001-09-25 14:23 ` David C. Hoos 2001-09-25 14:38 ` Marin David Condic @ 2001-09-25 23:03 ` Mark Johnson 2001-09-29 17:38 ` Tucker Taft 2 siblings, 1 reply; 15+ messages in thread From: Mark Johnson @ 2001-09-25 23:03 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-25 23:03 ` Mark Johnson @ 2001-09-29 17:38 ` Tucker Taft 2001-09-29 18:22 ` minyard 0 siblings, 1 reply; 15+ messages in thread From: Tucker Taft @ 2001-09-29 17:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-29 17:38 ` Tucker Taft @ 2001-09-29 18:22 ` minyard 2001-09-29 22:28 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: minyard @ 2001-09-29 18:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-29 18:22 ` minyard @ 2001-09-29 22:28 ` Jeffrey Carter 2001-09-30 13:10 ` Robert Dewar 2001-09-30 2:03 ` DuckE 2001-09-30 13:01 ` Robert Dewar 2 siblings, 1 reply; 15+ messages in thread From: Jeffrey Carter @ 2001-09-29 22:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-29 22:28 ` Jeffrey Carter @ 2001-09-30 13:10 ` Robert Dewar 2001-09-30 21:19 ` Jeffrey Carter 2001-10-02 9:38 ` AG 0 siblings, 2 replies; 15+ messages in thread From: Robert Dewar @ 2001-09-30 13:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-30 13:10 ` Robert Dewar @ 2001-09-30 21:19 ` Jeffrey Carter 2001-10-01 2:58 ` minyard 2001-10-02 9:38 ` AG 1 sibling, 1 reply; 15+ messages in thread From: Jeffrey Carter @ 2001-09-30 21:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-30 21:19 ` Jeffrey Carter @ 2001-10-01 2:58 ` minyard 0 siblings, 0 replies; 15+ messages in thread From: minyard @ 2001-10-01 2:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-30 13:10 ` Robert Dewar 2001-09-30 21:19 ` Jeffrey Carter @ 2001-10-02 9:38 ` AG 2001-10-02 10:59 ` Jeff Creem 1 sibling, 1 reply; 15+ messages in thread From: AG @ 2001-10-02 9:38 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-10-02 9:38 ` AG @ 2001-10-02 10:59 ` Jeff Creem 0 siblings, 0 replies; 15+ messages in thread From: Jeff Creem @ 2001-10-02 10:59 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-29 18:22 ` minyard 2001-09-29 22:28 ` Jeffrey Carter @ 2001-09-30 2:03 ` DuckE 2001-09-30 13:01 ` Robert Dewar 2 siblings, 0 replies; 15+ messages in thread From: DuckE @ 2001-09-30 2:03 UTC (permalink / raw) <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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-29 18:22 ` minyard 2001-09-29 22:28 ` Jeffrey Carter 2001-09-30 2:03 ` DuckE @ 2001-09-30 13:01 ` Robert Dewar 2001-09-30 20:12 ` minyard 2 siblings, 1 reply; 15+ messages in thread From: Robert Dewar @ 2001-09-30 13:01 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Pragma Volatile 2001-09-30 13:01 ` Robert Dewar @ 2001-09-30 20:12 ` minyard 0 siblings, 0 replies; 15+ messages in thread From: minyard @ 2001-09-30 20:12 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2001-10-02 10:59 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-09-25 14:07 Pragma Volatile Jon R. Harshaw 2001-09-25 14:23 ` David C. Hoos 2001-09-25 14:38 ` Marin David Condic 2001-09-25 23:03 ` Mark Johnson 2001-09-29 17:38 ` Tucker Taft 2001-09-29 18:22 ` minyard 2001-09-29 22:28 ` Jeffrey Carter 2001-09-30 13:10 ` Robert Dewar 2001-09-30 21:19 ` Jeffrey Carter 2001-10-01 2:58 ` minyard 2001-10-02 9:38 ` AG 2001-10-02 10:59 ` Jeff Creem 2001-09-30 2:03 ` DuckE 2001-09-30 13:01 ` Robert Dewar 2001-09-30 20:12 ` minyard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox