[Gc] Re: Powerpc/m68k issue running test_stack

Thorsten Glaser tg at mirbsd.de
Tue Nov 20 13:08:52 PST 2012


Dixi quod…

> Anyway, an idea why/how nthreads could be corrupted here?

Heh. Might want to look at whether the asm code trashes
registers because I just did this:

# ./test_stack2
Debug: nthreads=1; list_length=1
Debug: nthreads=2; list_length=3
Debug: nthreads=3; list_length=6
Debug: nthreads=4; list_length=10
About 1000000 pushes + 1000000 pops in 1 threads: 15780 msecs
About 1000000 pushes + 1000000 pops in 2 threads: 15840 msecs
About 1000000 pushes + 1000000 pops in 3 threads: 15820 msecs
About 1000000 pushes + 1000000 pops in 4 threads: 15960 msecs

After this:

root at aranym:~/libatomic_ops-7_2 # fgrep -C4 __sync_ src/atomic_ops/sysdeps/gcc/
m68k.h                           
AO_INLINE int
AO_compare_and_swap_full(volatile AO_t *addr,
                         AO_t old, AO_t new_val)
{
    return (int)__sync_bool_compare_and_swap(addr, old, new_val);
}
#define AO_HAVE_compare_and_swap_full

#include "../ao_t_is_int.h"

It’s, of course, much slower (as the GCC __sync_* builtins use the
kernel helper nowadays, which though is guaranteed to work, and not
suffer from any (past) emulation bugs or, worse, CAS bugs on real
metal (see the linux-m68k list for some recent explanation on those),
but at least it works.

So you might want to make libatomic-ops on m68k completely use just
the GCC (4.6) atomic builtins if available (I patched our GCC 4.6
to use the trunk code for them and offer them) and fall back to the
asm stuff only for old Linux and nōn-Linux like FreeMiNT.

Just an idea.

bye,
//mirabilos (still, please Cc me)



More information about the Gc mailing list