From mboxrd@z Thu Jan  1 00:00:00 1970
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: jvickers@dial.pipex.com (John Vickers), schwab@issan.informatik.uni-dortmund.de, smurf@noris.de, egcs@cygnus.com
Subject: Re: Incrementing volatiles?
Date: Mon, 13 Jul 1998 12:40:00 -0000
Message-id: <199807131639.JAA24602@cygnus.com>
References: <35A6B622.6F3EFF10@dial.pipex.com> <199807130936.LAA03530@mail.macqel.be>
X-SW-Source: 1998-07/msg00456.html

At 11:36 13.07.98 , Philippe De Muyter wrote:
>Sorry to be slightly off-topic, but this discussion reminds me a problem
>I encountered some months ago when writing a driver for a VME board in
>an AIX powerpc environment.  Although I had declared all the registers
>of the chips on the board as volatile, and compiled my driver with gcc,
>I saw with a logic analyser on the VME bus that the accesses to the
>register on the board were not done in the order I had written them.
>To solve that problem, I had to manually add asm("eieio") after each
>access to a volatile register.  Should gcc not do that for me ?

volatile has nothing to do with hardware instruction reordering.
asm("eieio") is an old-style asm and is an extremely strong barrier. I'm
currently testing this more optimization friendly solution in Linux/PPC, it
seems to work fine. 

extern inline int in_8(volatile unsigned char *addr)
{
        int ret;

        __asm__ __volatile__ ("" : "=m" (*addr) : "0" (*addr));
        ret = *addr;
        __asm__ __volatile__ ("eieio" : "=m" (*addr) : "0" (*addr));
        return ret;
}

extern inline void out_8(volatile unsigned char *addr, int val)
{
        __asm__ __volatile__ ("" : "=m" (*addr) : "0" (*addr));
        *addr = val;
        __asm__ __volatile__ ("eieio" : "=m" (*addr) : "0" (*addr));
}

Franz.