Date: Sat, 02 May 2009 13:01:07 -0600 From: tom fogal Subject: [Boost-users] Recent compilation troubles with gcc atomics To: boost-users@lists.boost.org Message-ID:

Hello all, http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html

In it, he notes that the availability of these builtins is not solely a function of the compiler version. In particular, the platform (CPU, OS, runtime support) seems to be a factor, as well as the backend code generation options (i.e. -march gcc compiler option).

He also suggests that the only reliable methodology for discovering the availability of these functions/builtins is by doing link-time tests. I mention as much because (unverified) I think boost's current solution is #ifdefs based on architecture and compiler version, which I think is fighting a losing battle.

I hope this information is useful for those stuck on the problem, and/or boost developers.

I'm in the middle of refactoring my "atomic_counter" templates, originally in the August 1998 issues of Visual C++ Developer (<http://www.dlugosz.com/Repertoire/refman/Classics/atomic_counter_white paper.html#toptop>). Besides design changes, it targets AMD-64. My experiments showed that the compiler's intrinsic support was spotty at best, and the documentation wasn't clear as to their availability. In particular, the VC++ compiler only generates intrinsic opcodes in 64-bit targets, and links to a library function for 32. The original issue is that the supplied API is too limited. If I want a post-increment (x++), the library function does the CPU opcode which is a post increment, then incs the result again to give the new value as the result, so then my code has to subtract it back out. Why dance around it? Furthermore, it didn't handle all different word sizes. More have been added to the win32 API, but it's still missing char! My latest solution is to expose them via functions written in assembly language. They cannot be inlined. But, the synchronized opcode is so slow anyway, and the call is now so cheap, being eaten by the prefetch stages, that I concluded that it didn't matter. On AMD-64, the calling convention was defined in the CPU's documentation so all platforms should follow it. The same functions should work for all operating systems, but would need macros for the actual (mangled C++) function names. Way back when, when doing it originally, I found that inline asm in an inline function in Microsoft's compiler didn't work out very well, since inlining would destroy the calling convention and values would be in the wrong registers before the body of the code! On the other hand, the WatCom compiler had a very good inline/intrinsic generator that would let you specify asm code to emit and which registers to set up for the inlined "call". I haven't seen that compiler in years, though. I'm tempted to make the new 32-bit version as a separate asm file, too, rather than inline asm. This will be more portable across different compilers and OS's, with the potential of using macros to give the correct C++ names, and if all compilers of interest can't generate the same "fastcall" calling, have prolog/epilog macros that takes the passed parameters and puts them in registers and cleans up the call, specified separately. And, use NASM to assemble it, which allows very powerful macros and can generate many target object file formats for the different operating systems. It's still x64 and x86 specific asm code. But the very concepts at this low level is CPU specific anyway. I notice the documentation for Windows on IA64 platform has "acquire/release" stuff. That is, different ways of doing it. Trying to sweet-talk each different compiler is a losing battle, especially since its supplied set of primitives is very incomplete. I conclude that just doing it in assembly language is easier. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.