[Info-vax] Volatile, was: Re: yet another sys$qiow question

[Jan-Erik Soderholm]

Den 2015-08-19 kl. 14:23, skrev Simon Clubley:
> On 2015-08-19, Bob Gezelter <gezelter at rlgsc.com> wrote:
>> On Tuesday, August 18, 2015 at 10:46:50 PM UTC-4, John Reagan wrote:
>>> On Tuesday, August 18, 2015 at 7:45:35 PM UTC-4, George Cornelius wrote:
>>>>
>>>> The whole volatile thing appears to have been a distraction.  As far as
>>>> I can tell, the C compiler never issues memory barrier instructions when
>>>> referencing volatile data, and, as John has pointed out, volatile is
>>>> not really needed as a hint to the compiler that the data might change
>>>> asynchronously as long as it already knows that the address of the
>>>> entity has been taken and passed to external code, because it
>>>> apparently has an internal implementation of a 'weakly volatile'
>>>> designation.  But if you do not synchronize, and it does change
>>>> between two successive calls to external code, the compiler is
>>>> free to remember, say, the value it read the first time in a
>>>> sequence of uninterrupted local code and not fetch it separately
>>>> each time thereafter.
>>>
>>> You don't need memory barriers.  You do need volatile.  The IOSB is
>>> written behind your back.  volatile says we have to re-fetch.
>>>
>>> I think you misunderstood my prior posts.  Places that only need a
>>> 'weak volatile' are places where you took the address of something
>>> (for example, put the address of a variable into an item list
>>> descriptor) and then call some system service that would write that
>>> variable for you.  But C doesn't have a weak volatile.  You can get
>>> away without using volatile, but in general, I'd recommend it at least
>>> for documentation purposes.
>>>
>>
>> John,
>>
>> Going back to Code Generation 101, I would think that a "volatile"
>> would only be relevant within a basic block. As I recall, the
>> definition of a basic block is "one entrance, one exit". Thus, an
>> out-of-line subroutine call ends a basic block by definition.
>>
>
> But the IOSB can be written by VMS if the I/O (started from elsewhere
> within the program) completes _while_ the basic block is executing.
>
>> I do not have my Alpha or IA64 architecture specification handy, but
>> what is the official definition concerning memory barriers and
>> subroutine calls/branches?
>>
>
> If I understand John correctly, that's not really the issue here.
> The issue is that the VMS design can change the contents of user
> space process specific memory (the address space allocated to the
> IOSB) behind the program's back without the program having to make
> an explicit call to update that memory.
>
> This is the classic case for the use of volatile in embedded systems.

Maybe that not all are familiar with the embedded world. :-)
Here are a couple of (very) simple examples.

VarA = 100
loop [some condition]
   VarB = VarA
endloop

Here the compiler will probably replace that with "VarB = 100", so
VarA is never referenced in the loop. If VarA is declared volatile,
the compiler will not do that but reference VarA in the loop.

Now in the embedded world we might have:

loop [some condition]
   VarB = PORTA
endloop

where PORTA is a hardware port (I/O pins) on the processor.

If PORTA is not volatile, the compiler can do a single read
of PORTA and then use a value saved in a processor register.
With volatile, the hardware I/O port will be read each time.

The "value" of PORTA can of course change at any time depending
on what happens in the hardware around the processor.

Now, in IDE's setup for this kind of development, this is of
course already taken care of in the processor include files
where symbols like PORTA are declared.

Jan-Erik.

>
> It also raises another very interesting issue. From what John appears
> to be saying, it sounds like the DEC compilers were written with this
> situation in mind.
>
> However, in this type of situation gcc can be really aggressive here
> about moving code around unless volatile is in use (this comes up on
> comp.arch.embedded on a regular basis). I don't use LLVM, but I wonder
> if code which works with DEC C will continue to work reliably with
> LLVM if LLVM is as aggressive as gcc at moving things around.
>
> Simon.
>