Re: [Boost-users] Boost-users Digest, Vol 1984, Issue 1

Subject: Re: [Boost-users] Boost-users Digest, Vol 1984, Issue 1
From: John Dlugosz (JDlugosz_at_[hidden])
Date: 2009-05-04 12:55:18

> Date: Sat, 02 May 2009 13:01:07 -0600
> From: tom fogal <tfogal_at_[hidden]>
> Subject: [Boost-users] Recent compilation troubles with gcc atomics
> To: boost-users_at_[hidden]
> Message-ID: <auto-000019291789_at_[hidden]>
> 
> 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.