Re: volatile shared memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Fri, Mar 16, 2012 at 9:47 AM, Andrew Haley <aph@xxxxxxxxxx> wrote:
> On 03/16/2012 01:36 PM, Jeffrey Walton wrote:
>> On Fri, Mar 16, 2012 at 9:25 AM, Andrew Haley <aph@xxxxxxxxxx> wrote:
>>> On 03/16/2012 01:14 PM, Jeffrey Walton wrote:
>
>
>>>> The reason I ask is Microsoft appears to have a different
>>>> interpretation of the qualifier [1], and does not limit 'volatile' to
>>>> memory mapped hardware.
>>>>
>>>> [1] http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.90).aspx
>>>
>>> It says "Microsoft Specific" ... "End Microsoft Specific" for
>>> a reason, y'know.
>> :)
>>
>> But the page does describe the keyword as "... a type qualifier used
>> to declare that an object can be modified in the program by something
>> such as the operating system, the hardware, or a concurrently
>> executing thread."
>
> That part is true, kinda sorta.
>
>> Ian's description is consistent with the GCC manual's description [1]:
>> "Both the C and C++ standard have the concept of volatile objects.
>> These are normally accessed by pointers and used for accessing
>> hardware." (Sorry about the 3.4.6 link in [1] - it was the first
>> Google hit from GCC man pages).
>>
>> Unfortunately, I've never seen the C or C++ definition of the keyword.
>>
>> Is 'volatile' implementation defined?
>
> Yes.
>
> ISO/IEC 9899:1999  6.7.3 Type qualifiers
>
> An object that has volatile-qualified type may be modified in ways
> unknown to the implementation or have other unknown side
> effects. Therefore any expression referring to such an object shall be
> evaluated strictly according to the rules of the abstract machine, as
> described in 5.1.2.3. Furthermore, at every sequence point the value
> last stored in the object shall agree with that prescribed by the
> abstract machine, except as modified by the unknown factors mentioned
> previously. What constitutes an access to an object that has
> volatile-qualified type is implementation-defined.
Ah, thanks Andrew.

I see they are referring to their wonderful abstract machine. That's
the same machine that has unlimited register sizes and never suffers
overflow or wrap. I should have known there was trouble afoot with the
differences in definitions between MS and GCC.

Jeff



[Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

Add to Google