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

[Johnny Billquist]

On 2015-08-19 14:36, Jan-Erik Soderholm wrote:
> Den 2015-08-19 kl. 14:23, skrev Simon Clubley:
>>
>> 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.

You did not go far enough, Jan-Erik.
The compiler would actually move the whole "VarB = VarA" before the 
loop, since it is an invariant. No point in repeating the same 
assignment a bunch of times. Once is enough.
If you declared VarB as volatile, it would instead optimize the way you 
suggested, sine then all the writes to VarB would have to be preserved.
If VarA was declared volatile, the whole assignment would have to be 
preserved in the loop. The same if both VarA and VarB was volatile.

> 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.

Right. Except that it would also move the assignment out of the loop if 
it wasn't volatile, as there is no point in repeating a constant assignment.

	Johnny