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

[Johnny Billquist]

On 2015-08-20 22:57, "VAXman- "@SendSpamHere.ORG wrote:
> In article <mr5au9$d3s$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>> On 2015-08-20 21:41, John Reagan wrote:
>>> On Thursday, August 20, 2015 at 3:15:38 PM UTC-4, JF Mezei wrote:
>>>> On 15-08-20 12:12, Simon Clubley wrote:
>>>>
>>>>> Will yes, that's how all compilers work because sys$qiow doesn't return
>>>>> control back to the program until it's completed so it's just like a
>>>>> normal subroutine call.
>>>>
>>>> The compiler doesn't know that. The compiler would/should treat both QIO
>>>> and QIOW as possibly modifying a value during their execution. Even if
>>>> QIO only modifies it later, that variable should be marked as "possibly
>>>> modified" by the compiler for the next time you access it, whether the
>>>> instriuction right after a QIOW or 10 instructions after QIO. Right ?
>>>>
>>>
>>> Well, yes, the FIRST access after $QIO will be a memory read.  However, since the asynchronous update may occur later, the compiler won't re-read the memory.
>>>
>>> For something like
>>>
>>> while (iosb == 0) do;
>>>
>>> It is not a loop of memory fetches (well, it might be at /NOOPT).  The optimizer will quickly turn that into:
>>>
>>> tmp = iosb;
>>> while (tmp == 0) do;
>>
>> I think an even better optimization would be:
>>
>> if (iosb == 0) while (1) {};
>>
>> And of course, when this ends up in assembler, it would actually be
>> (excuse my MACRO-11):
>>
>> 	TST	IOSB
>> 	BNE	10$
>> 20$:	BR	20$
>> 10$:
>>
>> I'm sure you can translate that to Macro-32 easily. :-)
>
> How did you define IOSB in the C?

The assumption was that the IOSB was not declared as volatile. With the 
above examples, iosb would have to be something int-like.

	Johnny