On 08/09/2013 12:59 PM, Joe Buck wrote:
On Fri, Aug 09, 2013 at 11:23:51AM -0500, Joel Sherrill wrote:
On 8/9/2013 11:05 AM, Deng Hengyi wrote:
Hi Joel,
I have done a test, it seems that '-march=i386' does not provide
"__atomic_compare_exchange_n" libs. And '-march=i486' or '-march=pentium' can
find the '__atomic_compare_exchange_n' function.
Look in the source for that methods on x86 and see what instruction
it used. If it only got added in i486, then we have to figure out
something for i386. If it was an oversight and the instruction is
on an i386, we fix the code.
The i386 architecture lacks atomic compare instructions, to the point
where libstdc++ can't be built with that architecture (correct and
efficient atomic operations are vital important for libstdc++, andon i386
it can't be done).
The worry is that if you add "atomic" operations that don't lock for the
i386 architecture, you've screwed anyone who decides to build their
application for i386 hoping for maximum portability, but winds up with
locks that don't lock.
You could perhaps handle that for RTEMS by providing these functions in a
library, but users need to understand this issue, because improper locks
are tough to debug.
libatomic provides a library implementations for all __atomic
operations. If the hardware doesn't have atomic operations, it will
utilize a lock to implement those routines.
At least thats the way its suppose to work :-) I have no idea if its
configured to build by default on 386 targets or not... I presume it is.
Andrew
