Re: GNU C keyword volatile, GNU compiler/optimizer and instruction re-ordering

Arun <Arun@Winphoria.Com> wrote:
>Now, we have a C code as follows:
>
> some_function() {
> volatile int *ptr1 = 0x60000000;
> volatile int *ptr2 = 0x60000004;
>
>Question is: can a C compiler/optimizer, specifically GNU C, re-order
>the assignment of *ptr1 and val? In other words, can variable val get
>assigned before *ptr1?
>
>In the same context, can processor pipelines in general re-order the
>instructions? Interesting cases may be the Intel's Pentium series and
>Motorola PowerPC. What if possible/any, are the hints by the
>compiler/optimizer to the processor?
>
>[The standard says that the generated code has to make all of the
>references to volatile data, in the order the program makes them.
>It also says that only lvalues can be volatile, so there's no such
>thing as a volatile function. -John]


Unfortunately, volatile is a complete mess. It was intended to cover
TWO purposes, one of which was such special memory locations and the
other of which relates to exception handling, longjmp etc. As with
many such compromises, it fails on both.


To a first approximation, the handling of volatile is implementation
dependent, and the only thing that is REQUIRED to be specified is
what constitutes and access to a volatile qualified object. Which
is not the issue here. Beyond that, it is the programmer's problem
to find out what, if anything, volatile means.


The reason for this is that ALL of the cases where volatile is
specified in the standard to affect the ordering can be detected ONLY
by a program that invokes undefined behaviour! Yes, really :-(


For example, in your code, the result of converting the integers to
pointers is implementation defined, but the use of any particular
integer value is not. So your program is outside the standard, and
the standard says nothing about what it will do.


So, the executive summary is to look in the gcc implementation notes
and see what, if anything, they say about this. They are not required
to specify the behaviour, and it is then undefined. But they may say
something. You can also look at the code and see what the current
version does, but there is no guarantee that the next one will do the
same thing.


Sorry.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679

Return to the comp.compilers page.
Search the comp.compilers archives again.