Is it possible that gcc reorders a series of read/write operations?

Is it possible that gcc reorders a series of read/write operations?

[Pan ruochen]

Hi All,
It is very common to read/write hardware registers frequently when
developing a hardware driver, like

$cat hw.c
#define HW_REG0  (volatile unsigned *)(HW_REG_BASE + 0x00)
#define HW_REG1  (volatile unsigned *)(HW_REG_BASE + 0x04)
...
#define HW_REGn  (volatile unsigned *)(HW_REG_BASE + 0xXX)

*HW_REG0 = 1;
*HW_REG1 = 4;
while( *HW_REG1 == 4 );
...
...

I wonder if there is any possibility that gcc reorders the read/write
operations in a way it thinks more optimal, which may be a disaster to
the hardware driver.

-------------
Best Regards,
PRC
Sep 3, 2008

Re: Is it possible that gcc reorders a series of read/write operations?

[me22]

On Tue, Sep 2, 2008 at 22:22, Pan ruochen <panruochen@gmail.com> wrote:
>
> I wonder if there is any possibility that gcc reorders the read/write
> operations in a way it thinks more optimal, which may be a disaster to
> the hardware driver.
>

I suspect that the volatile will prevent such things.

But just guessing,
~ Scott

Re: Is it possible that gcc reorders a series of read/write operations?

[Robert William Fuller]

Pan ruochen wrote:
> I wonder if there is any possibility that gcc reorders the read/write
> operations in a way it thinks more optimal, which may be a disaster to
> the hardware driver.

IIRC, the C compiler is required to maintain program order.  Hence, it 
should not re-order reads and writes.  However, if you do not declare a 
register as volatile, the compiler might optimize away something.  For 
example:

*HW_REG0=1;
*HW_REG0=4;

Might become simply:

*HW_REG0=4;

Rob

Re: Is it possible that gcc reorders a series of read/write operations?

[Marco Manfredini]

On Wednesday 03 September 2008, Pan ruochen wrote:
> Hi All,
> It is very common to read/write hardware registers frequently when
> developing a hardware driver, like
...
> I wonder if there is any possibility that gcc reorders the read/write
> operations in a way it thinks more optimal, which may be a disaster to
> the hardware driver.

The language guarantees that any operation on a 'volatile' object is complete 
when a sequence point is reached and that none of the subsequent operations 
on that volatile object will have been taken place. This prevents the 
compiler from reordering volatile accesses. However, that compiler has no 
knowledge about the underlying memory system - the CPU may reorder writes. 
Preventing this is quite hardware specific and may require hardware 
configuration or memory barriers.

Re: Is it possible that gcc reorders a series of read/write operations?

[David Daney]

Pan ruochen wrote:
> Hi All,
> It is very common to read/write hardware registers frequently when
> developing a hardware driver, like
> 
> $cat hw.c
> #define HW_REG0  (volatile unsigned *)(HW_REG_BASE + 0x00)
> #define HW_REG1  (volatile unsigned *)(HW_REG_BASE + 0x04)
> ...
> #define HW_REGn  (volatile unsigned *)(HW_REG_BASE + 0xXX)
> 
> *HW_REG0 = 1;
> *HW_REG1 = 4;
> while( *HW_REG1 == 4 );
> ...
> ...
> 
> I wonder if there is any possibility that gcc reorders the read/write
> operations in a way it thinks more optimal, which may be a disaster to
> the hardware driver.
> 

GCC shouldn't reorder the operations because you have them declared as 
'volatile', however I have a MIPS CPU where the hardware writeback 
buffer seems to do reordering...

David Daney

Re: Is it possible that gcc reorders a series of read/write operations?

[Pan ruochen]

> GCC shouldn't reorder the operations because you have them declared as
> 'volatile', however I have a MIPS CPU where the hardware writeback buffer
> seems to do reordering...
>
> David Daney
>

Can volatile do this? I thought volatile just forced GCC to read the
memory location each time rather than cahed the value in a register.
And I am interested in the details how your MIPS CPU hardware
reordered instructions.

Best Regard
-----------------
PRC
Sep 4, 2008

Re: Is it possible that gcc reorders a series of read/write operations?

[me22]

On Wed, Sep 3, 2008 at 21:11, Pan ruochen <panruochen@gmail.com> wrote:
>
> Can volatile do this? I thought volatile just forced GCC to read the
> memory location each time rather than cahed the value in a register.
> And I am interested in the details how your MIPS CPU hardware
> reordered instructions.
>

From the latest C++0x draft, section 1.9 [intro.execution]:

  The semantic descriptions in this International Standard define a
parameterized nondeterministic abstract
  machine. This International Standard places no requirement on the
structure of conforming implementations.
  In particular, they need not copy or emulate the structure of the
abstract machine. Rather, conforming
  implementations are required to emulate (only) the observable
behavior of the abstract machine as explained
  below.

  The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and
  calls to library I/O functions.

(That's not the whole story, and C or C++03 may have phrased it
differently, of course.)

HTH,
~ Scott

Re: Is it possible that gcc reorders a series of read/write operations?

[David Daney]

Pan ruochen wrote:
>> GCC shouldn't reorder the operations because you have them declared as
>> 'volatile', however I have a MIPS CPU where the hardware writeback buffer
>> seems to do reordering...
>>
>> David Daney
>>
> 
> Can volatile do this? I thought volatile just forced GCC to read the
> memory location each time rather than cahed the value in a register.

It does.  The problem I described is a hardware problem and has nothing 
to do with the compiler.

> And I am interested in the details how your MIPS CPU hardware
> reordered instructions.
> 

The instructions are executed in order.  The problem is that the write 
operations in IO space are sometimes reordered.  On this board, flushing 
the write-back buffer after IO writes is required.

David Daney

Re: Is it possible that gcc reorders a series of read/write operations?

[Pan ruochen]

> The instructions are executed in order.  The problem is that the write
> operations in IO space are sometimes reordered.  On this board, flushing the
> write-back buffer after IO writes is required.
>
> David Daney
>

Here, the write-back buffer means the instruction cache of MIPS?


PRC

Re: Is it possible that gcc reorders a series of read/write operations?

[David Daney]

Pan ruochen wrote:
>> The instructions are executed in order.  The problem is that the write
>> operations in IO space are sometimes reordered.  On this board, flushing the
>> write-back buffer after IO writes is required.
>>
>> David Daney
>>
> 
> Here, the write-back buffer means the instruction cache of MIPS?
> 
No.

It is separate from the caches and was intended to coalesce adjacent 
writes into a single wider write.  It had the problem that it could end 
up reordering the writes under some circumstances even through uncached 
portions of the address space.

David Daney

Re: Is it possible that gcc reorders a series of read/write operations?

[Pan ruochen]

> No.
>
> It is separate from the caches and was intended to coalesce adjacent writes
> into a single wider write.  It had the problem that it could end up
> reordering the writes under some circumstances even through uncached
> portions of the address space.
>
> David Daney
>

Is there any online document introducing hardware write reordering
about MIPS? I want to have a read
to get more details.

PRC
Sep 8, 2008

Re: Is it possible that gcc reorders a series of read/write operations?

[David Daney]

Pan ruochen wrote:
>> No.
>>
>> It is separate from the caches and was intended to coalesce adjacent writes
>> into a single wider write.  It had the problem that it could end up
>> reordering the writes under some circumstances even through uncached
>> portions of the address space.
>>
>> David Daney
>>
> 
> Is there any online document introducing hardware write reordering
> about MIPS? I want to have a read
> to get more details.

Each MIPS CPU is different.  Read the hardware manual and errata for the
particular CPU you are interested in.

David Daney