Hi,

I'm trying to implement atomic operations for floating point types for
Boost.Atomic and I'm stumbled about how the compare_exchange* operations
should behave with regard to special values like NaN and negative zero.
Neither P0020[1] nor N4713 clarify that.

My current implementation performs binary comparison of the stored
value, which means `a.compare_exchange(NaN)` would succeed if `a`
contains a NaN. Similarly, `a.compare_exchange(-0.0)` would fail if a
contains 0.0 (positive zero). This is opposite to the normal C++
behavior where NaN != NaN and -0 == 0 and I wanted to know if my current
behavior is still considered conforming.

As an implementation note, the FP operations basically map onto integer
atomic ops, so implementing the normal FP behavior would be difficult
and costly on performance. I'm not aware of architectures that implement
native atomic FP instructions, so I would expect these operations to be
implemented similarly to how I did. If that is considered an acceptable
behavior then I believe the standard should mention that. In that case,
is this a defect?

Thanks.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0020r6.html

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a110045-c4e8-4e80-3fed-aa8eb1bc0ec5%40gmail.com.

.

On 02/13/18 02:38, Andrey Semashev wrote:
> Hi,
>
> I'm trying to implement atomic operations for floating point types for
> Boost.Atomic and I'm stumbled about how the compare_exchange* operations
> should behave with regard to special values like NaN and negative zero.
> Neither P0020[1] nor N4713 clarify that.
>
> My current implementation performs binary comparison of the stored
> value, which means `a.compare_exchange(NaN)` would succeed if `a`
> contains a NaN. Similarly, `a.compare_exchange(-0.0)` would fail if a
> contains 0.0 (positive zero). This is opposite to the normal C++
> behavior where NaN != NaN and -0 == 0 and I wanted to know if my current
> behavior is still considered conforming.
>
> As an implementation note, the FP operations basically map onto integer
> atomic ops, so implementing the normal FP behavior would be difficult
> and costly on performance. I'm not aware of architectures that implement
> native atomic FP instructions, so I would expect these operations to be
> implemented similarly to how I did. If that is considered an acceptable
> behavior then I believe the standard should mention that. In that case,
> is this a defect?

Nevermind. I found the relevant note in [atomics.types.operations]/20
which says that `compare_exchange` has `memcmp` semantics.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5f50a481-0340-ab35-8793-22b119179e53%40gmail.com.

.

--089e08236510e71a15056511a88f
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 12, 2018 at 3:38 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> Hi,
>
> I'm trying to implement atomic operations for floating point types for
> Boost.Atomic and I'm stumbled about how the compare_exchange* operations
> should behave with regard to special values like NaN and negative zero.
> Neither P0020[1] nor N4713 clarify that.
>
> My current implementation performs binary comparison of the stored value,
> which means `a.compare_exchange(NaN)` would succeed if `a` contains a NaN.
> Similarly, `a.compare_exchange(-0.0)` would fail if a contains 0.0
> (positive zero). This is opposite to the normal C++ behavior where NaN !=
> NaN and -0 == 0 and I wanted to know if my current behavior is still
> considered conforming.
>
> As an implementation note, the FP operations basically map onto integer
> atomic ops, so implementing the normal FP behavior would be difficult and
> costly on performance. I'm not aware of architectures that implement native
> atomic FP instructions, so I would expect these operations to be
> implemented similarly to how I did. If that is considered an acceptable
> behavior then I believe the standard should mention that. In that case, is
> this a defect?
>

I don't know enough about the implementation to know if it is truly native,
but
http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#atomicadd
might be closer than what you'll find elsewhere.  The PTX docs indicate
this is an instruction (
http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-atom)
although that doesn't mean it isn't microcoded (or whatever the GPU
equivalent of that is) using compare-exchange.

There are some smart NVIDIA people involved in ISO C++ who might be able to
clarify this.

Obviously, the NVIDIA implementation may not be relevant if they don't
implement the IEEE754 semantics of interest.  They've written a paper on
that, but I don't have it cached in my head right now.

Jeff


> Thanks.
>
> [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0020r6.html
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/9a110045-c4e8-4e80-3fed-
> aa8eb1bc0ec5%40gmail.com.
>



--
Jeff Hammond
jeff.science@gmail.com
http://jeffhammond.github.io/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuJ7fkPqSvUaWUP9BZyPStN-HaU2moqLC86kX0%3DOBFeb1w%40mail.gmail.com.

--089e08236510e71a15056511a88f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Feb 12, 2018 at 3:38 PM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">Hi,<br>
<br>
I&#39;m trying to implement atomic operations for floating point types for =
Boost.Atomic and I&#39;m stumbled about how the compare_exchange* operation=
s should behave with regard to special values like NaN and negative zero. N=
either P0020[1] nor N4713 clarify that.<br>
<br>
My current implementation performs binary comparison of the stored value, w=
hich means `a.compare_exchange(NaN)` would succeed if `a` contains a NaN. S=
imilarly, `a.compare_exchange(-0.0)` would fail if a contains 0.0 (positive=
 zero). This is opposite to the normal C++ behavior where NaN !=3D NaN and =
-0 =3D=3D 0 and I wanted to know if my current behavior is still considered=
 conforming.<br>
<br>
As an implementation note, the FP operations basically map onto integer ato=
mic ops, so implementing the normal FP behavior would be difficult and cost=
ly on performance. I&#39;m not aware of architectures that implement native=
 atomic FP instructions, so I would expect these operations to be implement=
ed similarly to how I did. If that is considered an acceptable behavior the=
n I believe the standard should mention that. In that case, is this a defec=
t?<br></blockquote><div><br></div><div>I don&#39;t know enough about the im=
plementation to know if it is truly native, but=C2=A0<a href=3D"http://docs=
..nvidia.com/cuda/cuda-c-programming-guide/index.html#atomicadd">http://docs=
..nvidia.com/cuda/cuda-c-programming-guide/index.html#atomicadd</a> might be=
 closer than what you&#39;ll find elsewhere.=C2=A0 The PTX docs indicate th=
is is an instruction (<a href=3D"http://docs.nvidia.com/cuda/parallel-threa=
d-execution/index.html#parallel-synchronization-and-communication-instructi=
ons-atom">http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#=
parallel-synchronization-and-communication-instructions-atom</a>) although =
that doesn&#39;t mean it isn&#39;t microcoded (or whatever the GPU equivale=
nt of that is) using compare-exchange.</div><div><br></div><div>There are s=
ome smart NVIDIA people involved in ISO C++ who might be able to clarify th=
is.</div><div><br></div><div>Obviously, the NVIDIA implementation may not b=
e relevant if they don&#39;t implement the IEEE754 semantics of interest.=
=C2=A0 They&#39;ve written a paper on that, but I don&#39;t have it cached =
in my head right now.</div><div><br></div><div>Jeff</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
Thanks.<br>
<br>
[1]: <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p00=
20r6.html" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc=
1/s<wbr>c22/wg21/docs/papers/2017/p002<wbr>0r6.html</a><span class=3D"gmail=
-HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a110045-c4e8-4e80-3fed-aa8eb1bc0ec5%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/9a110045-c4e8-4e80-3fed-<wbr>=
aa8eb1bc0ec5%40gmail.com</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature">Jeff Hammond<br><a href=3D"mailto:jeff.sci=
ence@gmail.com" target=3D"_blank">jeff.science@gmail.com</a><br><a href=3D"=
http://jeffhammond.github.io/" target=3D"_blank">http://jeffhammond.github.=
io/</a></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuJ7fkPqSvUaWUP9BZyPStN-HaU2mo=
qLC86kX0%3DOBFeb1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuJ7fk=
PqSvUaWUP9BZyPStN-HaU2moqLC86kX0%3DOBFeb1w%40mail.gmail.com</a>.<br />

--089e08236510e71a15056511a88f--

.

On 02/13/18 08:56, Jeff Hammond wrote:
> On Mon, Feb 12, 2018 at 3:38 PM, Andrey Semashev=20
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>=20
>     As an implementation note, the FP operations basically map onto
>     integer atomic ops, so implementing the normal FP behavior would be
>     difficult and costly on performance. I'm not aware of architectures
>     that implement native atomic FP instructions, so I would expect
>     these operations to be implemented similarly to how I did. If that
>     is considered an acceptable behavior then I believe the standard
>     should mention that. In that case, is this a defect?
>=20
> I don't know enough about the implementation to know if it is truly=20
> native, but=20
> http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#atomicadd=
 might=20
> be closer than what you'll find elsewhere.=C2=A0 The PTX docs indicate th=
is=20
> is an instruction=20
> (http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#paralle=
l-synchronization-and-communication-instructions-atom)=20
> although that doesn't mean it isn't microcoded (or whatever the GPU=20
> equivalent of that is) using compare-exchange.
>=20
> There are some smart NVIDIA people involved in ISO C++ who might be able=
=20
> to clarify this.
>=20
> Obviously, the NVIDIA implementation may not be relevant if they don't=20
> implement the IEEE754 semantics of interest.=C2=A0 They've written a pape=
r on=20
> that, but I don't have it cached in my head right now.

I see, thanks for the links. They don't seem to provide `atomicCAS` for=20
FP types, but given the example of `atomicAdd` implemented on top of=20
`atomicCAS`, the intention is to perform bitwise comparison.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1fd0d836-6080-4845-2740-8c23c49831fb%40gmail.com=
..

.

--001a113b5716b8a05105651853a1
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 13, 2018 at 2:40 AM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 02/13/18 08:56, Jeff Hammond wrote:
>
>> On Mon, Feb 12, 2018 at 3:38 PM, Andrey Semashev <
>> andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>>
>>     As an implementation note, the FP operations basically map onto
>>     integer atomic ops, so implementing the normal FP behavior would be
>>     difficult and costly on performance. I'm not aware of architectures
>>     that implement native atomic FP instructions, so I would expect
>>     these operations to be implemented similarly to how I did. If that
>>     is considered an acceptable behavior then I believe the standard
>>     should mention that. In that case, is this a defect?
>>
>> I don't know enough about the implementation to know if it is truly
>> native, but http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.
>> html#atomicadd might be closer than what you'll find elsewhere.  The PTX
>> docs indicate this is an instruction (http://docs.nvidia.com/cuda/p
>> arallel-thread-execution/index.html#parallel-synchronization
>> -and-communication-instructions-atom) although that doesn't mean it
>> isn't microcoded (or whatever the GPU equivalent of that is) using
>> compare-exchange.
>>
>> There are some smart NVIDIA people involved in ISO C++ who might be able
>> to clarify this.
>>
>> Obviously, the NVIDIA implementation may not be relevant if they don't
>> implement the IEEE754 semantics of interest.  They've written a paper on
>> that, but I don't have it cached in my head right now.
>>
>
> I see, thanks for the links. They don't seem to provide `atomicCAS` for FP
> types, but given the example of `atomicAdd` implemented on top of
> `atomicCAS`, the intention is to perform bitwise comparison.
>

CAS is the standard way to implement atomics when native implementations
don't exist but equality comparison of floating-point numbers is
problematic, so one should not explicitly support that, unless the C
operator is explicitly beq (bitwise-equality) and not implicitly leq
(logical-equality).  Forcing programmers to implement FP CAS with casts to
integer types makes the bitwise comparison more obvious.

For example, the mathematically inclined might expect CAS(x,0.5) to behave
the same as CAS(x,0.1+0.1+0.1+0.1+0.1) and CAS(x,5.0*0.1), but they don't,
and their behavior may depend on a bunch of factors the programmer can't
see.

However, the common pattern of looping over CAS to emulate arithmetic
floating-point is fine, since one is using comparison to determine if
anybody else has modified the bits since a prior load.  It's essentially a
software implementation of LLSC.

Jeff

PS Memory models and floating-point arithmetic are two of the most nuanced
topics in computer programming, so what I've written above almost certainly
has flaws proportional to the reader's expertise in these topics.  I used
weasel words like "fine" and "essentially" on purpose :-)

--
Jeff Hammond
jeff.science@gmail.com
http://jeffhammond.github.io/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuJW743%3DmP%2BeuL6mEkczdEvgRwOApFhpXEFhsFWzO_%2BxgQ%40mail.gmail.com.

--001a113b5716b8a05105651853a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Feb 13, 2018 at 2:40 AM, Andrey Semashev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semas=
hev@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02=
/13/18 08:56, Jeff Hammond wrote:<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Mon, Feb 12, 2018 at 3:38 PM, Andrey Semashev &lt;<a href=3D"mailto:andr=
ey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a> &lt;=
mailto:<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andre=
y.semashev@gmail.<wbr>com</a>&gt;&gt; wrote:<br>
<br>
=C2=A0 =C2=A0 As an implementation note, the FP operations basically map on=
to<br>
=C2=A0 =C2=A0 integer atomic ops, so implementing the normal FP behavior wo=
uld be<br>
=C2=A0 =C2=A0 difficult and costly on performance. I&#39;m not aware of arc=
hitectures<br>
=C2=A0 =C2=A0 that implement native atomic FP instructions, so I would expe=
ct<br>
=C2=A0 =C2=A0 these operations to be implemented similarly to how I did. If=
 that<br>
=C2=A0 =C2=A0 is considered an acceptable behavior then I believe the stand=
ard<br>
=C2=A0 =C2=A0 should mention that. In that case, is this a defect?<br>
<br>
I don&#39;t know enough about the implementation to know if it is truly nat=
ive, but <a href=3D"http://docs.nvidia.com/cuda/cuda-c-programming-guide/in=
dex.html#atomicadd" rel=3D"noreferrer" target=3D"_blank">http://docs.nvidia=
..com/cuda/cu<wbr>da-c-programming-guide/index.<wbr>html#atomicadd</a> might=
 be closer than what you&#39;ll find elsewhere.=C2=A0 The PTX docs indicate=
 this is an instruction (<a href=3D"http://docs.nvidia.com/cuda/parallel-th=
read-execution/index.html#parallel-synchronization-and-communication-instru=
ctions-atom" rel=3D"noreferrer" target=3D"_blank">http://docs.nvidia.com/cu=
da/p<wbr>arallel-thread-execution/index<wbr>.html#parallel-synchronization<=
wbr>-and-communication-<wbr>instructions-atom</a>) although that doesn&#39;=
t mean it isn&#39;t microcoded (or whatever the GPU equivalent of that is) =
using compare-exchange.<br>
<br>
There are some smart NVIDIA people involved in ISO C++ who might be able to=
 clarify this.<br>
<br>
Obviously, the NVIDIA implementation may not be relevant if they don&#39;t =
implement the IEEE754 semantics of interest.=C2=A0 They&#39;ve written a pa=
per on that, but I don&#39;t have it cached in my head right now.<br>
</blockquote>
<br></span>
I see, thanks for the links. They don&#39;t seem to provide `atomicCAS` for=
 FP types, but given the example of `atomicAdd` implemented on top of `atom=
icCAS`, the intention is to perform bitwise comparison.<span class=3D""><br=
></span></blockquote><div><br></div><div>CAS is the standard way to impleme=
nt atomics when native implementations don&#39;t exist but equality compari=
son of floating-point numbers is problematic, so one should not explicitly =
support that, unless the C operator is explicitly beq (bitwise-equality) an=
d not implicitly leq (logical-equality).=C2=A0 Forcing programmers to imple=
ment FP CAS with casts to integer types makes the bitwise comparison more o=
bvious.</div><div><br></div><div>For example, the mathematically inclined m=
ight expect CAS(x,0.5) to behave the same as CAS(x,0.1+<span style=3D"color=
:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:norm=
al;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;l=
etter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-d=
ecoration-style:initial;text-decoration-color:initial;float:none;display:in=
line">0.1+</span><span style=3D"color:rgb(34,34,34);font-family:arial,sans-=
serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-=
variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;=
text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;bac=
kground-color:rgb(255,255,255);text-decoration-style:initial;text-decoratio=
n-color:initial;float:none;display:inline">0.1+</span><span style=3D"color:=
rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:norma=
l;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;le=
tter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-de=
coration-style:initial;text-decoration-color:initial;float:none;display:inl=
ine">0.1+</span><span style=3D"color:rgb(34,34,34);font-family:arial,sans-s=
erif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-v=
ariant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;back=
ground-color:rgb(255,255,255);text-decoration-style:initial;text-decoration=
-color:initial;float:none;display:inline">0.1) and CAS(x,5.0*0.1), but they=
 don&#39;t, and their behavior may depend on a bunch of factors the program=
mer can&#39;t see.</span></div><div><span style=3D"color:rgb(34,34,34);font=
-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-lig=
atures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:norma=
l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w=
ord-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:ini=
tial;text-decoration-color:initial;float:none;display:inline"><br></span></=
div><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;fo=
nt-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-=
caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-ind=
ent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-=
color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:=
initial;float:none;display:inline">However, the common pattern of looping o=
ver CAS to emulate arithmetic floating-point is fine, since one is using co=
mparison to determine if anybody else has modified the bits since a prior l=
oad.=C2=A0 It&#39;s essentially a software implementation of LLSC.</span></=
div><div><br></div><div><span style=3D"color:rgb(34,34,34);font-family:aria=
l,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:norma=
l;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align=
:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-de=
coration-color:initial;float:none;display:inline">Jeff</span></div><div><sp=
an style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:smal=
l;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;=
font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(25=
5,255,255);text-decoration-style:initial;text-decoration-color:initial;floa=
t:none;display:inline"><br></span></div><div><span style=3D"color:rgb(34,34=
,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-va=
riant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spac=
ing:normal;text-align:start;text-indent:0px;text-transform:none;white-space=
:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-=
style:initial;text-decoration-color:initial;float:none;display:inline">PS M=
emory models and floating-point arithmetic are two of the most nuanced topi=
cs in computer programming, so what I&#39;ve written above almost certainly=
 has flaws proportional to the reader&#39;s expertise in these topics.=C2=
=A0 I used weasel words like &quot;fine&quot; and &quot;essentially&quot; o=
n purpose :-)</span></div><div><br></div></div>-- <br><div class=3D"gmail_s=
ignature" data-smartmail=3D"gmail_signature">Jeff Hammond<br><a href=3D"mai=
lto:jeff.science@gmail.com" target=3D"_blank">jeff.science@gmail.com</a><br=
><a href=3D"http://jeffhammond.github.io/" target=3D"_blank">http://jeffham=
mond.github.io/</a></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGKz%3DuJW743%3DmP%2BeuL6mEkczdEvgRw=
OApFhpXEFhsFWzO_%2BxgQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGKz%3Du=
JW743%3DmP%2BeuL6mEkczdEvgRwOApFhpXEFhsFWzO_%2BxgQ%40mail.gmail.com</a>.<br=
 />

--001a113b5716b8a05105651853a1--

.