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

[VAXman- at SendSpamHere.ORG]

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?


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.