[boost] [shared_ptr] m68k and ia64 implementations by Ben Hutchings, RFC
Ben Hutchings has kindly contributed the attached sp_counted_base implementations for g++ on IA64 and 68020+. The IA64 version of decrement should be changed to: Ben Hutchings wrote:
It isn't a memory barrier (unless you add .acq or .rel to it) but I don't believe a barrier is needed for the simple increment and decrement operations. It is always atomic, like lock xadd.
For increment, no. For decrement, yes. It needs to be a release when the new value is nonzero,
Oh yes, of course it does.
and an acquire when the new value is zero.
Hmm, tricky. There would be need to be another instruction afterward that creates the acquire barrier. Maybe this would do:
__asm__ (" fetchaddl.rel %0=[%4],-1 \n" " cmp.eq %2,%3=1,%0 \n" "(%2) ldl.acq %0=[%4] " : "=r"(rv), "=m"(*pw), "=c", "=c" : "r"(pw) : );
Don't ask me whether that's the most efficient way to do this!
In your (Boost developers) opinion, 1. Do we need a platform-specific version for 68020+ at all? (It is my understanding that threads aren't very popular there ;-) but I may be wrong) 2. Should we try to get an IA64 version in 1.33 or should this be postponed for 1.34?
Peter Dimov wrote:
In your (Boost developers) opinion,
1. Do we need a platform-specific version for 68020+ at all? (It is my understanding that threads aren't very popular there ;-) but I may be wrong)
Are we able to maintain (esp. to test) an 68K version? Given the resource requirements for testing, I suspect we'd need a crosscompilation setup or an emulator (or even both) for this. As much as I'd like to see an 68K version I also have to admit there isn't much demand for it.
2. Should we try to get an IA64 version in 1.33 or should this be postponed for 1.34? #ifndef BOOST_DETAIL_SP_COUNTED_BASE_GCC_IA64_HPP_INCLUDED #define BOOST_DETAIL_SP_COUNTED_BASE_GCC_IA64_HPP_INCLUDED
This should probably get decided by the release manager and you. If you add it then please do it soon since the change will likely trigger another recompilation of everything. Regards, m
Peter Dimov wrote: [...]
and an acquire when the new value is zero.
Hmm, tricky. There would be need to be another instruction afterward that creates the acquire barrier. Maybe this would do:
__asm__ (" fetchaddl.rel %0=[%4],-1 \n" " cmp.eq %2,%3=1,%0 \n" "(%2) ldl.acq %0=[%4] " : "=r"(rv), "=m"(*pw), "=c", "=c" : "r"(pw) : );
Don't ask me whether that's the most efficient way to do this!
That's RAW dependency on a semaphore. It isn't optimal for refcounting because it equates to a full fence, not mere acquire. BTW, you need a "memory" clobber clause here (not sure about cc/predicate stuff). regards, alexander.
Peter Dimov wrote: [...]
------------------------------------------------------------------------ Name: sp_counted_base_gcc_ia64.hpp sp_counted_base_gcc_ia64.hpp Type: Plain Text (text/plain) Encoding: 7bit
: inline void atomic_increment( long * pw ) : { : // ++*pw; : : long tmp; : : __asm__ ("fetchaddl %0=[%2],1" : : "=r"(tmp), "=m"(*pw) : : "r"(pw) : : ); : } That's implicit .acq by default, right? Release incarnation is probably better. It merely "delays" increment and doesn't hinder value prediction for subsequent loads and other speculative stuff for "all" subsequent operations. regards, alexander.
participants (2)
-
Alexander Terekhov -
Martin Wille -
Peter Dimov