Re: [boost] [shared_ptr] Using inline assembler, Microsoft syntax in Linux, and shared pointers

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-10-25 19:10:57

Ovidiu Cristea wrote:
> All,
>
> To make a long story short, here's my situation:
> - we just upgraded to boost 1.33 from 1.32;
> - trying to compile on Linux (Windows will follow soon); we're mostly
> using gcc, with the exception of some pieces that we use Intel C++
> 9.x for; - some piece of the code I'm trying to build uses boost
> shared pointers
> and, being a port from Windows, inline Microsoft-style assembler code;
> - the rest of my 'world' is built in an environment that causes
> boost/detail/sp_counted_base_gcc_x86.hpp to be used for the shared_ptr
> locking.
>
> The problem I ran into is that, well,
> boost/detail/sp_counted_base_gcc_x86.hpp contains gnu-style inline
> assembler, and icc (intel C++ compiler) refuses to mix the 2 assembler
> styles in one file.

A very unusual situation. :-)

> After a little snooping around, I found that there is a file called
> boost/detail/sp_counted_base_cw_x86.hpp, which contains the equivalent
> functionality as *gcc_x86.hpp, only written in Microsoft-style
> assembly.
> I rigged it to use this and it 'seems' to work.
>
> And now for the questions:
> - is there any reason why in my release the #include of the
> *cw_x86.hpp
> file was commented out? Is it not performing as it should? Any other
> reasons?

It wasn't tested as extensively as the others and there was no need for it 
since CodeWarrior/Windows works with sp_counted_base_w32.

> - is it safe for me to compile part of my classes with *gcc_x86.hpp,
> and part with *cw_x86.hpp?

In principle, this is a violation of the One Definition Rule... In practice, 
it should work.

> - if the above answers are 'favorable', is it possible for future
> releases to include a way for people to easily have the MS-assembly
> file included instead of the gnu one?

It would probably be better to introduce an Intel-specific sp_counted_base 
that uses its intrinsics. I don't know whether the Intel compiler for Linux 
supports the _Interlocked* family, though; or whether the following 
intrinsics:

http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html

that were originally introduced in icc/ia64 (and later adopted by g++ 4.1) 
work under icc/x86.