[atomic] unconditional cmpxchg8b support
hi helge & list, using boost.atomic on ia32/gcc causes me quite some headaches these days, as the cmpxchg8b instruction is enabled via the __i686__ or __x86_64__ macros. however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction. whatever, i wonder if it would be reasonable to enable cmpxchg8b by default on *all* ia32 platforms, not just on i686. advantage: less trouble, as we can be sure that the instruction is generated. boost.lockfree e.g. is not lockfree on ia32 without. disadvantage: the code won't work on i386 and i486 machines. imo, all ia32 machines without cmpxchg8b should belong to a museum, and we could introduce a macro like BOOST_ATOMIC_NO_CMPXCHG8B if we really care of compiling for any of those machines. thoughts? tim
On Oct 23, 2012 1:41 PM, "Tim Blechmann" <tim@klingt.org> wrote:
hi helge & list,
using boost.atomic on ia32/gcc causes me quite some headaches these days, as the cmpxchg8b instruction is enabled via the __i686__ or __x86_64__ macros. however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction.
whatever, i wonder if it would be reasonable to enable cmpxchg8b by default on *all* ia32 platforms, not just on i686. advantage: less trouble, as we can be sure that the instruction is generated. boost.lockfree e.g. is not lockfree on ia32 without. disadvantage: the code won't work on i386 and i486 machines.
imo, all ia32 machines without cmpxchg8b should belong to a museum, and we could introduce a macro like BOOST_ATOMIC_NO_CMPXCHG8B if we really care of compiling for any of those machines.
thoughts?
I think the library should be fair and compile for the platform it is requested for. The question of the default target platform should be directed to compiler or Debian dev team.
imo, all ia32 machines without cmpxchg8b should belong to a museum, and we could introduce a macro like BOOST_ATOMIC_NO_CMPXCHG8B if we really care of compiling for any of those machines.
thoughts?
I think the library should be fair and compile for the platform it is requested for. The question of the default target platform should be directed to compiler or Debian dev team.
in theory i'd agree with you, but i doubt that it is easy to convince the debian devs to change their defaults ... and then we (well i) may still have problems with other linux distributions, maybe mingw/cygwin ...
On Tue, 23 Oct 2012, Tim Blechmann wrote:
imo, all ia32 machines without cmpxchg8b should belong to a museum, and we could introduce a macro like BOOST_ATOMIC_NO_CMPXCHG8B if we really care of compiling for any of those machines.
thoughts?
I think the library should be fair and compile for the platform it is requested for. The question of the default target platform should be directed to compiler or Debian dev team.
in theory i'd agree with you, but i doubt that it is easy to convince the debian devs to change their defaults ... and then we (well i) may still have problems with other linux distributions, maybe mingw/cygwin ...
I guess that you will have a difficult time convincing them, as such things are preferentially handled at run-time (ld-linux hwcaps being prefered probably). That's certainly doable in boost.atomic (except for the hwcaps part, would have to use cpuid directly, probably). Cheers, Helge
On 23/10/12 12:21, Tim Blechmann wrote:
imo, all ia32 machines without cmpxchg8b should belong to a museum, and we could introduce a macro like BOOST_ATOMIC_NO_CMPXCHG8B if we really care of compiling for any of those machines.
thoughts?
I think the library should be fair and compile for the platform it is requested for. The question of the default target platform should be directed to compiler or Debian dev team.
in theory i'd agree with you, but i doubt that it is easy to convince the debian devs to change their defaults ... and then we (well i) may still have problems with other linux distributions, maybe mingw/cygwin ...
Why not instruct the compiler to build for the platform you want to build for instead?
I think the library should be fair and compile for the platform it is requested for. The question of the default target platform should be directed to compiler or Debian dev team.
in theory i'd agree with you, but i doubt that it is easy to convince the debian devs to change their defaults ... and then we (well i) may still have problems with other linux distributions, maybe mingw/cygwin ...
Why not instruct the compiler to build for the platform you want to build for instead?
my users are barely capable of handling a build system, not to mention a compiler ... artists who are eager to user open source, you know
AMDG On 10/23/2012 05:29 AM, Tim Blechmann wrote:
I think the library should be fair and compile for the platform it is requested for. The question of the default target platform should be directed to compiler or Debian dev team.
in theory i'd agree with you, but i doubt that it is easy to convince the debian devs to change their defaults ... and then we (well i) may still have problems with other linux distributions, maybe mingw/cygwin ...
Why not instruct the compiler to build for the platform you want to build for instead?
my users are barely capable of handling a build system, not to mention a compiler ... artists who are eager to user open source, you know
Seriously, if the compiler is set to compile for an architecture that doesn't support cmpxchg8b, then Boost.Atomic should not generate this instruction. I really don't care if disregarding this makes things easier for some people. We have to follow consistent rules or eventually no will be able to understand what's going on. In Christ, Steven Watanabe
Steven Watanabe wrote:
Seriously, if the compiler is set to compile for an architecture that doesn't support cmpxchg8b, then Boost.Atomic should not generate this instruction.
It's very, very rare for a user to willingly target 386/486 (these processors are all but extinct, not to mention that modern Windows versions simply don't run on them.) A GCC target of i386 in practice simply means that a target hasn't been set, not that the user explicitly wanted to target i386. Nobody wants to target i386.
On Oct 24, 2012 1:22 AM, "Peter Dimov" <lists@pdimov.com> wrote:
Steven Watanabe wrote:
Seriously, if the compiler is set to compile for an architecture that doesn't support cmpxchg8b, then Boost.Atomic should not generate this instruction.
It's very, very rare for a user to willingly target 386/486 (these
processors are all but extinct, not to mention that modern Windows versions simply don't run on them.) Windows is not the only OS Boost supports.
A GCC target of i386 in practice simply means that a target hasn't been set, not that the user explicitly wanted to target i386. Nobody wants to target i386.
The library should not make this assumption. Unless the library explicitly requires particular hardware to run on in the docs, it should compile and run on any CPU. Whether or not Boost.Atomic should require cmpxchg8b on x86 is a valid question. If it does require that, the library should not compile for a target not meeting that requirement. The user should be made aware that the library does not support that target. IMO, it is not acceptable to silently compile the code that requires higher hw capabilities than specified by compiler, however unusual they may be. IMHO, there is no hard requirement of cmpxchg8b on x86. Most of the library is still useful without it.
On Wed, Oct 24, 2012 at 00:22:01 +0300, Peter Dimov wrote:
Steven Watanabe wrote:
Seriously, if the compiler is set to compile for an architecture that doesn't support cmpxchg8b, then Boost.Atomic should not generate this instruction.
It's very, very rare for a user to willingly target 386/486 (these processors are all but extinct, not to mention that modern Windows versions simply don't run on them.)
They are extinct in desktop. Not necessarily true of embedded systems.
A GCC target of i386 in practice simply means that a target hasn't been set, not that the user explicitly wanted to target i386. Nobody wants to target i386.
gcc target i486-linux-gnu means somebody explicitly configured that target. Since that's how it is configured in both Debian and Ubutnu, it's set in stone at least until April 2017 (Precise end-of-life). Note though, that there is no longer any supported version not shipping gcc with __sync_* support. -- Jan 'Bulb' Hudec <bulb@ucw.cz>
Jan Hudec wrote:
On Wed, Oct 24, 2012 at 00:22:01 +0300, Peter Dimov wrote:
Steven Watanabe wrote:
Seriously, if the compiler is set to compile for an architecture that doesn't support cmpxchg8b, then Boost.Atomic should not generate this instruction.
It's very, very rare for a user to willingly target 386/486 (these processors are all but extinct, not to mention that modern Windows versions simply don't run on them.)
They are extinct in desktop. Not necessarily true of embedded systems.
I can imagine embedded 486 systems still existing, but a default should be right for the 99.9% of the users, not for the 0.1% who can easily use something like #define BOOST_ATOMIC_NO_CMPXCHG8B.
On 23/10/12 23:22, Peter Dimov wrote:
Steven Watanabe wrote:
Seriously, if the compiler is set to compile for an architecture that doesn't support cmpxchg8b, then Boost.Atomic should not generate this instruction.
It's very, very rare for a user to willingly target 386/486 (these processors are all but extinct, not to mention that modern Windows versions simply don't run on them.)
A GCC target of i386 in practice simply means that a target hasn't been set, not that the user explicitly wanted to target i386. Nobody wants to target i386.
Three possible solutions: - educate your users - recommend that your users use a 64-bit distribution where the defaults will be better - make your build system do what you need it to do transparently. If in practice the program you're making should run on the same machine as the one you're building it on, you may for example detect what the machine building it supports and enable the appropriate compilation flags.
On 23/10/12 11:40, Tim Blechmann wrote:
hi helge & list,
using boost.atomic on ia32/gcc causes me quite some headaches these days, as the cmpxchg8b instruction is enabled via the __i686__ or __x86_64__ macros. however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction.
GCC will not let you use instructions outside of the target architecture. This is normal and expected behaviour.
using boost.atomic on ia32/gcc causes me quite some headaches these days, as the cmpxchg8b instruction is enabled via the __i686__ or __x86_64__ macros. however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction.
GCC will not let you use instructions outside of the target architecture.
fyi, boost.atomic is using inline assembly
On 23/10/12 13:46, Tim Blechmann wrote:
using boost.atomic on ia32/gcc causes me quite some headaches these days, as the cmpxchg8b instruction is enabled via the __i686__ or __x86_64__ macros. however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction.
GCC will not let you use instructions outside of the target architecture.
fyi, boost.atomic is using inline assembly
While inline assembly may allow to circumvent that restriction, I do not think it is a good idea to force a design that requires their usage.
however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction.
GCC will not let you use instructions outside of the target architecture.
fyi, boost.atomic is using inline assembly
While inline assembly may allow to circumvent that restriction, I do not think it is a good idea to force a design that requires their usage.
in a perfect world, we would not need boost.atomic, as all compilers, standard libraries would be c++11 compliant. helge might want to comment about his decision to use inline assembly, but iirc, gcc did not provide good support for atomic builtins until 4.4 or so ... so portability would be a reason
On Tue, Oct 23, 2012 at 14:28:46 +0200, Tim Blechmann wrote:
however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction.
GCC will not let you use instructions outside of the target architecture.
fyi, boost.atomic is using inline assembly
While inline assembly may allow to circumvent that restriction, I do not think it is a good idea to force a design that requires their usage.
in a perfect world, we would not need boost.atomic, as all compilers, standard libraries would be c++11 compliant.
helge might want to comment about his decision to use inline assembly, but iirc, gcc did not provide good support for atomic builtins until 4.4 or so ... so portability would be a reason
gcc __sync functions were introduced in gcc 4.1. Some of them were introduced later, but __sync_val_compare_and_swap is there from the start. Developing for mobile platforms and thus non-intel architectures, I would really prefer if boost used the __sync operations whenever available. That would cover non-ancient gcc targeting either ancient (the Debian case) or esoteric (the embedded case) CPUs. -- Jan 'Bulb' Hudec <bulb@ucw.cz>
participants (7)
-
Andrey Semashev -
Helge Bahmann -
Jan Hudec -
Mathias Gaunard -
Peter Dimov -
Steven Watanabe -
Tim Blechmann