Re[2]: [Gc] Should libatomic_ops be inside bdwgc?

[Ivan Maidanski]

Hi Petter,

Thank you for the explanation. But my Q was really about operations set not about types width to be supported.

Regards.

18 08 2011, 11:04 Petter Urkedal <urkedal at nbi.dk>:
> On 2011-08-17, Ivan Maidanski wrote:
> > Hi Petter and Hans,
> >
> > Is the current libatomic_ops API sufficient to implement the complete C++0x atomics API? (Or, we don't need to implement all the C++0x primitives, do we?)
> 
> I can answer part of that question.  The AO_t may be to narrow to
> implement all the atomic_X_t types.  In the ISO/IEC:TC2 draft which I'm
> using as my C99 reference, the corresponding stdint.h are optional
> (7.18.1.1.3):
> 
>     These types are optional. However, if an implementation provides
>     integer types with widths of 8, 16, 32, or 64 bits, no padding bits,
>     and (for the signed types) that have a two’s complement
>     representation, it shall define the corresponding typedef names.
> 
> Not sure if that changed in the final standard.  On the other hand N1349
> does not state that the atomic_X_t types are optional, but since my
> reference[1] is a proposal, that may change.
> 
> In any case, I think it'll suffice for our purpose to only implement up
> to the word size.  In the long run the stdatomic.h header will be
> shipped by the compiler vendor anyway.
> 
> > A sub-question: what's about CAS? I mean do we need a CAS variant returning old-value to implement the corresponding C++0x primitive?
> 
> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1349.htm
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>