[Gc] Re: Powerpc/m68k issue running test_stack
tg at mirbsd.de
Tue Nov 20 13:08:52 PST 2012
> 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:
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
root at aranym:~/libatomic_ops-7_2 # fgrep -C4 __sync_ src/atomic_ops/sysdeps/gcc/
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);
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.
//mirabilos (still, please Cc me)
More information about the Gc