Re: gcc 3.2.3 config/os/bits/i386/atomicity.h broken

[Andreas Jaeger <aj at suse dot de>]

Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com> writes:

> In article <hosms3ghgs dot fsf at byrd dot suse dot de> Andreas write:
>>> [...]
>>> However, the patch within implies to me that plain xchgl will fail on
>>> x86-64 (would a compiler configured as i386-*-* be expected to support
>>> x86-64? was the patch pessimistic?):
>
>>>   http://www.x86-64.org/lists/discuss/msg01969.html
>
>>> (The reason, I'm questioning above, is because I don't know.  I recall
>>> that the 68K weakened the strength of TAS between 000 and 0[12]0 when
>>> they added support for MP and a new bus locking protocol.  But that
>>> was a lifetime ago.)
>
>> xchgl will work correctly on x86-64.  The only problem (and that's why
>> it was disabled temporarily in the patch you mentioned) is that
>> arguments to it might have a different size.
>
> Andreas,
>
> I really want to fix 3.3 before release, if possible.  Could you tell
> me how to write this code for generic i386 yet still run properly on
> x86-64?  Is it merely a matter of pointing to a larger space than
> required for a plain i386?  How about using `xchgb' instead of
> 'xchgl'?  We only need one sole bit of atomic swap space for the
> algorithm proposed.  As an authority on the x86-64, I'd really
> appreciate any time you'd spend thinking about it.

Sorry, one question: Which file exactly is meant?

config/os/bits/i386/atomicity.h does only exist in 3.2.x, on 3.3 we
have config/cpu/i486/atomicity.h and that file looks fine to me and
can be used without changes for both x86_64 and i486 (already
configured this way in configure.target).

Speaking about this implementation:
static inline _Atomic_word
__attribute__ ((__unused__))
__exchange_and_add (volatile _Atomic_word *__mem, int __val)
{
  register _Atomic_word __result, __tmp;
  static volatile _Atomic_word __lock = 1;

 /* obtain the atomic exchange/add lock */
  do {
    __tmp = 0;
    __asm__ __volatile__("xchgl %0,%1"
             :"=r" (__tmp)
             :"m" (&__lock), "0" (__lock)
             :"memory");
  } while ( __tmp == 0 );
  
    __result = *__mem;
    *__mem += __val;
  
  /* release spin lock */
  __lock = 1;

  return __result;
}

I do not see a reason why this should not work on x86-64.  The x86-64
manuals specify for xchgl that "if a memory operand is involved, the
locking protocol of the processor is automatically implemented,
regardless of the presense or absence of the LOCK prefix...", so this
should work - and it compiles for both x86 and x86-64.

I would prefer to use the i486 implementation and perhaps use this
only for i386.  The problem I see here is more performance,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj at suse dot de
   private aj at arthur dot inka dot de
    http://www.suse.de/~aj