Re: [Gc] Should libatomic_ops be inside bdwgc?
ivmai at mail.ru
Thu Aug 18 00:17:27 PDT 2011
Thank you for the explanation. But my Q was really about operations set not about types width to be supported.
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
> 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 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?
>  https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1349.htm
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc