--000000000000a10437056c80f894
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This might be interesting.

In some systems, the implementation of memcpy() & friends cannot be used
for memory-mapped devices.
Usually, mapped memory is marked as volatile.

I'm proposing to add volatile pointers overloads for the memcpy() function
and friends, without specifying exactly what should be different at the
standard-level, but allowing implementations to provide a particular
behavior. I'm just proposing to add the declaration to the standard.

Particularly, in some x86-based systems, reading things like the SPI should
be done on byte-per-byte basis (rather than streamed with any SIMD
instruction).

I'm not sure what the wording should exactly say, but I'm just initiating
the discussion.

    Daniel.

--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-0NAvWrkwzpgEKq4DQj%3D0vL_0F2s17XyR9MSUNJk=
5R0sw%40mail.gmail.com.

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

<div dir=3D"ltr">This might be interesting.<div><br></div><div>In some syst=
ems, the implementation of memcpy() &amp; friends cannot be used for memory=
-mapped devices.</div><div>Usually, mapped memory is marked as volatile.</d=
iv><div><br></div><div>I&#39;m proposing to add volatile pointers overloads=
 for the memcpy() function and friends, without specifying exactly what sho=
uld be different at the standard-level, but allowing implementations to pro=
vide a particular behavior. I&#39;m just proposing to add the declaration t=
o the standard.</div><div><br></div><div>Particularly, in some x86-based sy=
stems, reading things like the SPI should be done on byte-per-byte basis (r=
ather than streamed with any SIMD instruction).</div><div><br></div><div>I&=
#39;m not sure what the wording should exactly say, but I&#39;m just initia=
ting the discussion.</div><div><br></div><div>=C2=A0 =C2=A0 Daniel.<br clea=
r=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature" data-smartma=
il=3D"gmail_signature">Who=E2=80=99s got the sweetest disposition?<br>One g=
uess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<b=
r>Who never shows a bit of temperament?<br>Who&#39;s never wrong but always=
 right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck with=
 all the bad luck? </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/CAFdMc-0NAvWrkwzpgEKq4DQj%3D0vL_0F2s1=
7XyR9MSUNJk5R0sw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0NAvWrkw=
zpgEKq4DQj%3D0vL_0F2s17XyR9MSUNJk5R0sw%40mail.gmail.com</a>.<br />

--000000000000a10437056c80f894--

.

On 05/18/18 23:41, dgutson . wrote:
> This might be interesting.
>
> In some systems, the implementation of memcpy() & friends cannot be used
> for memory-mapped devices.
> Usually, mapped memory is marked as volatile.
>
> I'm proposing to add volatile pointers overloads for the memcpy()
> function and friends, without specifying exactly what should be
> different at the standard-level, but allowing implementations to provide
> a particular behavior. I'm just proposing to add the declaration to the
> standard.
>
> Particularly, in some x86-based systems, reading things like the SPI
> should be done on byte-per-byte basis (rather than streamed with any
> SIMD instruction).
>
> I'm not sure what the wording should exactly say, but I'm just
> initiating the discussion.

If it's not specified then the exact behavior wrt. memory accesses is
not going to be portable, which means it's not going to be useful.

--
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/0e5ce74c-3e9e-4cf2-4afd-f7333ed82c5d%40gmail.com.

.

--00000000000008e487056c8124da
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 18, 2018 at 5:46 PM, Andrey Semashev <andrey.semashev@gmail.com=
>
wrote:

> On 05/18/18 23:41, dgutson . wrote:
>
>> This might be interesting.
>>
>> In some systems, the implementation of memcpy() & friends cannot be used
>> for memory-mapped devices.
>> Usually, mapped memory is marked as volatile.
>>
>> I'm proposing to add volatile pointers overloads for the memcpy()
>> function and friends, without specifying exactly what should be differen=
t
>> at the standard-level, but allowing implementations to provide a particu=
lar
>> behavior. I'm just proposing to add the declaration to the standard.
>>
>> Particularly, in some x86-based systems, reading things like the SPI
>> should be done on byte-per-byte basis (rather than streamed with any SIM=
D
>> instruction).
>>
>> I'm not sure what the wording should exactly say, but I'm just initiatin=
g
>> the discussion.
>>
>
> If it's not specified then the exact behavior wrt. memory accesses is not
> going to be portable, which means it's not going to be useful.


It is useful indeed: if I have a pointer to volatile memory, I cannot use
memcpy currently.
By adding the overload, I'm being guaranteed that I will be able to call
memcpy (and that the implementation shall DTRT, which is for example, the
byte per byte copying).
Besides the "DTRT" discussion, my point is: I want this overload to be
available. At least it should fall back to the non-volatile version.


>
>
> --
> 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/0e5ce74c-3e9e-4cf2-4afd-
> f7333ed82c5d%40gmail.com.
>



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-3V0VJ9nOs2fg4OuRr4N8TG-VXsrek1v%3DCJpr%3D=
Bqt98%2BQ%40mail.gmail.com.

--00000000000008e487056c8124da
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 Fri, May 18, 2018 at 5:46 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On 05/18/18 23:41, dgutson . wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
This might be interesting.<br>
<br>
In some systems, the implementation of memcpy() &amp; friends cannot be use=
d for memory-mapped devices.<br>
Usually, mapped memory is marked as volatile.<br>
<br>
I&#39;m proposing to add volatile pointers overloads for the memcpy() funct=
ion and friends, without specifying exactly what should be different at the=
 standard-level, but allowing implementations to provide a particular behav=
ior. I&#39;m just proposing to add the declaration to the standard.<br>
<br>
Particularly, in some x86-based systems, reading things like the SPI should=
 be done on byte-per-byte basis (rather than streamed with any SIMD instruc=
tion).<br>
<br>
I&#39;m not sure what the wording should exactly say, but I&#39;m just init=
iating the discussion.<br>
</blockquote>
<br></span>
If it&#39;s not specified then the exact behavior wrt. memory accesses is n=
ot going to be portable, which means it&#39;s not going to be useful.</bloc=
kquote><div><br></div><div>It is useful indeed: if I have a pointer to vola=
tile memory, I cannot use memcpy currently.</div><div>By adding the overloa=
d, I&#39;m being guaranteed that I will be able to call memcpy (and that th=
e implementation shall DTRT, which is for example, the byte per byte copyin=
g).</div><div>Besides the &quot;DTRT&quot; discussion, my point is: I want =
this overload to be available. At least it should fall back to the non-vola=
tile version.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"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/0e5ce74c-3e9e-4cf2-4afd-f7333ed82c5d%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/0e5ce74c-3e9e-4cf2-4afd-<wbr>=
f7333ed82c5d%40gmail.com</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=
=80=99s got the sweetest disposition?<br>One guess, that=E2=80=99s who?<br>=
Who=E2=80=99d never, ever start an argument?<br>Who never shows a bit of te=
mperament?<br>Who&#39;s never wrong but always right?<br>Who&#39;d never dr=
eam of starting a fight?<br>Who get stuck with all the bad luck? </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/CAFdMc-3V0VJ9nOs2fg4OuRr4N8TG-VXsrek1=
v%3DCJpr%3DBqt98%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3V0V=
J9nOs2fg4OuRr4N8TG-VXsrek1v%3DCJpr%3DBqt98%2BQ%40mail.gmail.com</a>.<br />

--00000000000008e487056c8124da--

.

On 05/18/18 23:53, dgutson . wrote:
>
> On Fri, May 18, 2018 at 5:46 PM, Andrey Semashev
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>
>     On 05/18/18 23:41, dgutson . wrote:
>
>         This might be interesting.
>
>         In some systems, the implementation of memcpy() & friends cannot
>         be used for memory-mapped devices.
>         Usually, mapped memory is marked as volatile.
>
>         I'm proposing to add volatile pointers overloads for the
>         memcpy() function and friends, without specifying exactly what
>         should be different at the standard-level, but allowing
>         implementations to provide a particular behavior. I'm just
>         proposing to add the declaration to the standard.
>
>         Particularly, in some x86-based systems, reading things like the
>         SPI should be done on byte-per-byte basis (rather than streamed
>         with any SIMD instruction).
>
>         I'm not sure what the wording should exactly say, but I'm just
>         initiating the discussion.
>
>     If it's not specified then the exact behavior wrt. memory accesses
>     is not going to be portable, which means it's not going to be useful.
>
> It is useful indeed: if I have a pointer to volatile memory, I cannot
> use memcpy currently.
> By adding the overload, I'm being guaranteed that I will be able to call
> memcpy (and that the implementation shall DTRT, which is for example,
> the byte per byte copying).
> Besides the "DTRT" discussion, my point is: I want this overload to be
> available. At least it should fall back to the non-volatile version.

What is "the right thing"? Does it have to be a byte-granular operation?
Does it have to be a forward iteration? Is this behavior the same on all
implementations? You have to answer on all these questions in the
standard wording so that everyone can rely on the exact memory access
pattern, which is important in case of volatile memory.

If it is not important in your case then you don't need volatile and
hence the overload.

Personally, I don't see much use in such an overload. Where memory
access pattern is important I would rather spell it explicitly or at
least use std::copy, which, unlike memcpy, does define the order of
iteration and granularity.

--
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/dc37b3f7-74b8-b94f-0a1c-59bb99ecbccc%40gmail.com.

.

On Friday, 18 May 2018 14:13:15 PDT Andrey Semashev wrote:
> What is "the right thing"? Does it have to be a byte-granular operation?
> Does it have to be a forward iteration? Is this behavior the same on all
> implementations? You have to answer on all these questions in the
> standard wording so that everyone can rely on the exact memory access
> pattern, which is important in case of volatile memory.
>
> If it is not important in your case then you don't need volatile and
> hence the overload.

On the other hand, if your memory storage requires a specific behaviour which
cannot be standardised, maybe you should implement the copying directly in
your code. It's not like bytewise memcpy and memset are particularly difficult
to implement...

It's the SIMD-optimised with cacheline-alignment and such that are.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/2300193.1RphyUdPvq%40tjmaciei-mobl1.

.

--0000000000005fecf4056c84ef4a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El vie., 18 de mayo de 2018 21:16, Thiago Macieira <thiago@macieira.org>
escribi=C3=B3:

> On Friday, 18 May 2018 14:13:15 PDT Andrey Semashev wrote:
> > What is "the right thing"? Does it have to be a byte-granular operation=
?
> > Does it have to be a forward iteration? Is this behavior the same on al=
l
> > implementations? You have to answer on all these questions in the
> > standard wording so that everyone can rely on the exact memory access
> > pattern, which is important in case of volatile memory.
> >
> > If it is not important in your case then you don't need volatile and
> > hence the overload.
>
> On the other hand, if your memory storage requires a specific behaviour
> which
> cannot be standardised, maybe you should implement the copying directly i=
n
> your code. It's not like bytewise memcpy and memset are particularly
> difficult
> to implement...
>

Oh yes you don't know how hard it can get... :) avoid prefetching, avoid
SSE/vectorization, ensure right order of operations (WC regions).
So there are lots of details that a too smart toolchain may mess.
However I will think if an execution policy can help here in copy. I'm not
talking about copying but also memsetting.
The linux kernel has a nice memcpy_toio/fromio worth to look at.



> It's the SIMD-optimised with cacheline-alignment and such that are.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> 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/2300193.1Rph=
yUdPvq%40tjmaciei-mobl1
> .
>

--=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/CAFdMc-0wber%2BdL_ugAcg7OBxLoajOOU8mMqLmS-aKTWHR=
cCghQ%40mail.gmail.com.

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El vie., 18 de mayo de 2018 21:16, Thiago Macieira &lt;<a href=3D"mailto:th=
iago@macieira.org">thiago@macieira.org</a>&gt; escribi=C3=B3:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">On Friday, 18 May 2018 14:13:15 PDT Andrey Semas=
hev wrote:<br>
&gt; What is &quot;the right thing&quot;? Does it have to be a byte-granula=
r operation?<br>
&gt; Does it have to be a forward iteration? Is this behavior the same on a=
ll<br>
&gt; implementations? You have to answer on all these questions in the<br>
&gt; standard wording so that everyone can rely on the exact memory access<=
br>
&gt; pattern, which is important in case of volatile memory.<br>
&gt; <br>
&gt; If it is not important in your case then you don&#39;t need volatile a=
nd<br>
&gt; hence the overload.<br>
<br>
On the other hand, if your memory storage requires a specific behaviour whi=
ch <br>
cannot be standardised, maybe you should implement the copying directly in =
<br>
your code. It&#39;s not like bytewise memcpy and memset are particularly di=
fficult <br>
to implement...<br></blockquote></div></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Oh yes you don&#39;t know how hard it can get... :) avoid pr=
efetching, avoid SSE/vectorization, ensure right order of operations (WC re=
gions).</div><div dir=3D"auto">So there are lots of details that a too smar=
t toolchain may mess.</div><div dir=3D"auto">However I will think if an exe=
cution policy can help here in copy. I&#39;m not talking about copying but =
also memsetting.</div><div dir=3D"auto">The linux kernel has a nice memcpy_=
toio/fromio worth to look at.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<br>
It&#39;s the SIMD-optimised with cacheline-alignment and such that are.<br>
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer noreferrer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" rel=3D"noreferrer noreferrer" target=3D"_blank">kde.org=
</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<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" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/2300193.1RphyUdPvq%40tjmaciei-mobl1" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://groups.google.com/a=
/isocpp.org/d/msgid/std-proposals/2300193.1RphyUdPvq%40tjmaciei-mobl1</a>.<=
br>
</blockquote></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/CAFdMc-0wber%2BdL_ugAcg7OBxLoajOOU8mM=
qLmS-aKTWHRcCghQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-0wber%2B=
dL_ugAcg7OBxLoajOOU8mMqLmS-aKTWHRcCghQ%40mail.gmail.com</a>.<br />

--0000000000005fecf4056c84ef4a--

.

On Friday, 18 May 2018 18:24:37 PDT dgutson . wrote:
> Oh yes you don't know how hard it can get...  avoid prefetching, avoid
> SSE/vectorization, ensure right order of operations (WC regions).
> So there are lots of details that a too smart toolchain may mess.

Even with volatile? It can't change the accesses you make if you use volatile.
So no prefetching, no SSE. The order is exactly the one that you specify.

> However I will think if an execution policy can help here in copy. I'm not
> talking about copying but also memsetting.
> The linux kernel has a nice memcpy_toio/fromio worth to look at.

Does it work for other types of memory besides I/O/

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/6528826.uWXH5iz4YB%40tjmaciei-mobl1.

.

On 05/19/2018 03:24 AM, dgutson . wrote:
>=20
>=20
> El vie., 18 de mayo de 2018 21:16, Thiago Macieira <thiago@macieira.org <=
mailto:thiago@macieira.org>> escribi=C3=B3:
>=20
>     On Friday, 18 May 2018 14:13:15 PDT Andrey Semashev wrote:
>     > What is "the right thing"? Does it have to be a byte-granular opera=
tion?
>     > Does it have to be a forward iteration? Is this behavior the same o=
n all
>     > implementations? You have to answer on all these questions in the
>     > standard wording so that everyone can rely on the exact memory acce=
ss
>     > pattern, which is important in case of volatile memory.
>     >
>     > If it is not important in your case then you don't need volatile an=
d
>     > hence the overload.
>=20
>     On the other hand, if your memory storage requires a specific behavio=
ur which
>     cannot be standardised, maybe you should implement the copying direct=
ly in
>     your code. It's not like bytewise memcpy and memset are particularly =
difficult
>     to implement...
>=20
>=20
> Oh yes you don't know how hard it can get... :) avoid prefetching, avoid =
SSE/vectorization, ensure right order of operations (WC regions).
> So there are lots of details that a too smart toolchain may mess.
> However I will think if an execution policy can help here in copy. I'm no=
t talking about copying but also memsetting.
> The linux kernel has a nice memcpy_toio/fromio worth to look at.

"volatile" only conveys a single bit of information, but
modern architectures need a lot more data to actually do
what you want if the "memory" isn't your usual kind of
RAM with a cache hierarchy on top.  For example, it might
make a difference whether you copy bytewise or wordwise (and
both options might be useful in different circumstances).
For example, you might need to expressly synchronize writes
with later reads.

Since you mention the Linux kernel, note that it has a lot
more than just a volatile memcpy to deal with all these
issues.  Maybe there's a general enough abstraction hidden
in there somewhere that we could eventually standardize, but
just having a volatile memcpy is neither here nor there.

Jens

--=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/5B0520CD.30204%40gmx.net.

.

--000000000000a1e528056cdf8c8f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 23, 2018 at 5:05 AM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> On 05/19/2018 03:24 AM, dgutson . wrote:
> >
> >
> > El vie., 18 de mayo de 2018 21:16, Thiago Macieira <thiago@macieira.org
> <mailto:thiago@macieira.org>> escribi=C3=B3:
> >
> >     On Friday, 18 May 2018 14:13:15 PDT Andrey Semashev wrote:
> >     > What is "the right thing"? Does it have to be a byte-granular
> operation?
> >     > Does it have to be a forward iteration? Is this behavior the same
> on all
> >     > implementations? You have to answer on all these questions in the
> >     > standard wording so that everyone can rely on the exact memory
> access
> >     > pattern, which is important in case of volatile memory.
> >     >
> >     > If it is not important in your case then you don't need volatile
> and
> >     > hence the overload.
> >
> >     On the other hand, if your memory storage requires a specific
> behaviour which
> >     cannot be standardised, maybe you should implement the copying
> directly in
> >     your code. It's not like bytewise memcpy and memset are particularl=
y
> difficult
> >     to implement...
> >
> >
> > Oh yes you don't know how hard it can get... :) avoid prefetching, avoi=
d
> SSE/vectorization, ensure right order of operations (WC regions).
> > So there are lots of details that a too smart toolchain may mess.
> > However I will think if an execution policy can help here in copy. I'm
> not talking about copying but also memsetting.
> > The linux kernel has a nice memcpy_toio/fromio worth to look at.
>
> "volatile" only conveys a single bit of information, but
> modern architectures need a lot more data to actually do
> what you want if the "memory" isn't your usual kind of
> RAM with a cache hierarchy on top.  For example, it might
> make a difference whether you copy bytewise or wordwise (and
> both options might be useful in different circumstances).
> For example, you might need to expressly synchronize writes
> with later reads.
>
> Since you mention the Linux kernel, note that it has a lot
> more than just a volatile memcpy to deal with all these
> issues.  Maybe there's a general enough abstraction hidden
> in there somewhere that we could eventually standardize, but
> just having a volatile memcpy is neither here nor there.
>

OK, agree.

To provide some context to other readers: (despite these are kernel-space
issues, but it should apply)
    https://lwn.net/Articles/698014/
    https://wiki.gentoo.org/wiki/MTRR_and_PAT

I think that we could think about some requirements packed in something
like a memory_traits, where it would specify:
  - pointer type (optionally volatile-qualified)
  - alignment requirements
  - memory synchronization needs / specifications (an enumerator)
  - vectorization habilities

The challenge is to turn this implementation agnostic enogh so
implementations can fill in the values.

Then we could provide memory primitives overloads (memcpy, memset, or
std::copy, etc.) receiving the memory_traits type as template argument.

This is related to transactional memory, std::memory_order, and other
fences and memory barriers. So maybe the traits would pack this information
plus other bits?





>
> Jens
>
> --
> 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/5B0520CD.30204%40gmx.net.
>



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-3mTTm5hUovuzz51TrJKW8HhVRBjt8kf1obvN0g%3D=
%2BOMhg%40mail.gmail.com.

--000000000000a1e528056cdf8c8f
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 Wed, May 23, 2018 at 5:05 AM, Jens Maurer <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.net</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On=
 05/19/2018 03:24 AM, dgutson . wrote:<br>
<span class=3D"gmail-">&gt; <br>
&gt; <br>
&gt; El vie., 18 de mayo de 2018 21:16, Thiago Macieira &lt;<a href=3D"mail=
to:thiago@macieira.org">thiago@macieira.org</a> &lt;mailto:<a href=3D"mailt=
o:thiago@macieira.org">thiago@macieira.org</a>&gt;&gt; escribi=C3=B3:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On Friday, 18 May 2018 14:13:15 PDT Andrey Semashev=
 wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; What is &quot;the right thing&quot;? Does it h=
ave to be a byte-granular operation?<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; Does it have to be a forward iteration? Is thi=
s behavior the same on all<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; implementations? You have to answer on all the=
se questions in the<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; standard wording so that everyone can rely on =
the exact memory access<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; pattern, which is important in case of volatil=
e memory.<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; If it is not important in your case then you d=
on&#39;t need volatile and<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; hence the overload.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On the other hand, if your memory storage requires =
a specific behaviour which<br>
&gt;=C2=A0 =C2=A0 =C2=A0cannot be standardised, maybe you should implement =
the copying directly in<br>
&gt;=C2=A0 =C2=A0 =C2=A0your code. It&#39;s not like bytewise memcpy and me=
mset are particularly difficult<br>
&gt;=C2=A0 =C2=A0 =C2=A0to implement...<br>
&gt; <br>
&gt; <br>
&gt; Oh yes you don&#39;t know how hard it can get... :) avoid prefetching,=
 avoid SSE/vectorization, ensure right order of operations (WC regions).<br=
>
&gt; So there are lots of details that a too smart toolchain may mess.<br>
&gt; However I will think if an execution policy can help here in copy. I&#=
39;m not talking about copying but also memsetting.<br>
&gt; The linux kernel has a nice memcpy_toio/fromio worth to look at.<br>
<br>
</span>&quot;volatile&quot; only conveys a single bit of information, but<b=
r>
modern architectures need a lot more data to actually do<br>
what you want if the &quot;memory&quot; isn&#39;t your usual kind of<br>
RAM with a cache hierarchy on top.=C2=A0 For example, it might<br>
make a difference whether you copy bytewise or wordwise (and<br>
both options might be useful in different circumstances).<br>
For example, you might need to expressly synchronize writes<br>
with later reads.<br>
<br>
Since you mention the Linux kernel, note that it has a lot<br>
more than just a volatile memcpy to deal with all these<br>
issues.=C2=A0 Maybe there&#39;s a general enough abstraction hidden<br>
in there somewhere that we could eventually standardize, but<br>
just having a volatile memcpy is neither here nor there.<br></blockquote><d=
iv><br></div><div>OK, agree.</div><div><br></div><div>To provide some conte=
xt to other readers: (despite these are kernel-space issues, but it should =
apply)</div><div>=C2=A0 =C2=A0 <a href=3D"https://lwn.net/Articles/698014/"=
>https://lwn.net/Articles/698014/</a><br></div><div>=C2=A0 =C2=A0 <a href=
=3D"https://wiki.gentoo.org/wiki/MTRR_and_PAT">https://wiki.gentoo.org/wiki=
/MTRR_and_PAT</a><br></div><div><br></div><div>I think that we could think =
about some requirements packed in something like a memory_traits, where it =
would specify:</div><div>=C2=A0 - pointer type (optionally volatile-qualifi=
ed)</div><div>=C2=A0 - alignment requirements</div><div>=C2=A0 - memory syn=
chronization needs / specifications (an enumerator)</div><div>=C2=A0 - vect=
orization habilities</div><div><br></div><div>The challenge is to turn this=
 implementation agnostic enogh so implementations can fill in the values.</=
div><div><br></div><div>Then we could provide memory primitives overloads (=
memcpy, memset, or std::copy, etc.) receiving the memory_traits type as tem=
plate argument.</div><div><br></div><div>This is related to transactional m=
emory, std::memory_order, and other fences and memory barriers. So maybe th=
e traits would pack this information plus other bits?</div><div><br></div><=
div><br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
<br>
Jens<br>
<span class=3D"gmail-"><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">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/5B0520CD.30204%40gmx.net" rel=
=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.o=
rg/d/msgid/std-<wbr>proposals/5B0520CD.30204%<wbr>40gmx.net</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature">Who=E2=80=99s got the sweetest disposition?<br>One gue=
ss, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br>=
Who never shows a bit of temperament?<br>Who&#39;s never wrong but always r=
ight?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck with a=
ll the bad luck? </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/CAFdMc-3mTTm5hUovuzz51TrJKW8HhVRBjt8k=
f1obvN0g%3D%2BOMhg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3mTTm5=
hUovuzz51TrJKW8HhVRBjt8kf1obvN0g%3D%2BOMhg%40mail.gmail.com</a>.<br />

--000000000000a1e528056cdf8c8f--

.

On Wednesday, 23 May 2018 10:31:15 -03 dgutson . wrote:
> I think that we could think about some requirements packed in something
> like a memory_traits, where it would specify:
>   - pointer type (optionally volatile-qualified)
>   - alignment requirements
>   - memory synchronization needs / specifications (an enumerator)
>   - vectorization habilities

Or, like I said, you can roll out your own memcpy or memset (which are quite
trivial) if you have specific requirements.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1695197.Kxq4M8jdJr%40tjmaciei-mobl1.

.

--00000000000026e3b3056ce1401d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 23, 2018 at 12:13 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Wednesday, 23 May 2018 10:31:15 -03 dgutson . wrote:
> > I think that we could think about some requirements packed in something
> > like a memory_traits, where it would specify:
> >   - pointer type (optionally volatile-qualified)
> >   - alignment requirements
> >   - memory synchronization needs / specifications (an enumerator)
> >   - vectorization habilities
>
> Or, like I said, you can roll out your own memcpy or memset (which are
> quite
> trivial) if you have specific requirements.
>

I propose to leave "triviality" out of the discussion, since this can get
combinatoric complex, and there is no metric of "triviality" either.
There are many std functions that are arguably trivial as well, and despite
that, they are in the STL because people use them.
We can keep arguing about triviality, what is trivial and what isn't, and
we will end up comparing somebody with Hitler as per Godwin's Law.
Please forgive me, I sincerely respect you but this is not a discussion I
would like to have.


>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> 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/1695197.Kxq4M8jdJr%40tjmaciei-mobl1.
>



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-2o%3DSKNdmiy_fnnWWJ%2B3%2BZkbh2sKU4pks40h=
gS3md%3DMNA%40mail.gmail.com.

--00000000000026e3b3056ce1401d
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 Wed, May 23, 2018 at 12:13 PM, Thiago Macieira <span dir=3D"ltr">&lt=
;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.o=
rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
>On Wednesday, 23 May 2018 10:31:15 -03 dgutson . wrote:<br>
&gt; I think that we could think about some requirements packed in somethin=
g<br>
&gt; like a memory_traits, where it would specify:<br>
&gt;=C2=A0 =C2=A0- pointer type (optionally volatile-qualified)<br>
&gt;=C2=A0 =C2=A0- alignment requirements<br>
&gt;=C2=A0 =C2=A0- memory synchronization needs / specifications (an enumer=
ator)<br>
&gt;=C2=A0 =C2=A0- vectorization habilities<br>
<br>
</span>Or, like I said, you can roll out your own memcpy or memset (which a=
re quite <br>
trivial) if you have specific requirements.<br></blockquote><div><br></div>=
<div>I propose to leave &quot;triviality&quot; out of the discussion, since=
 this can get combinatoric complex, and there is no metric of &quot;trivial=
ity&quot; either.</div><div>There are many std functions that are arguably =
trivial as well, and despite that, they are in the STL because people use t=
hem.</div><div>We can keep arguing about triviality, what is trivial and wh=
at isn&#39;t, and we will end up comparing somebody with Hitler as per Godw=
in&#39;s Law.</div><div>Please forgive me, I sincerely respect you but this=
 is not a discussion I would like to have.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<span class=3D""><br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
</span><span class=3D"">-- <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">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/1695197.Kxq4M8jdJr%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/1695197.Kxq4M8jdJr%<wbr>40tjmaciei-=
mobl1</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got t=
he sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d=
 never, ever start an argument?<br>Who never shows a bit of temperament?<br=
>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of starti=
ng a fight?<br>Who get stuck with all the bad luck? </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/CAFdMc-2o%3DSKNdmiy_fnnWWJ%2B3%2BZkbh=
2sKU4pks40hgS3md%3DMNA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-2o=
%3DSKNdmiy_fnnWWJ%2B3%2BZkbh2sKU4pks40hgS3md%3DMNA%40mail.gmail.com</a>.<br=
 />

--00000000000026e3b3056ce1401d--

.

--00000000000093e581056ce1469b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 23, 2018 at 12:33 PM, dgutson . <danielgutson@gmail.com> wrote:

>
>
> On Wed, May 23, 2018 at 12:13 PM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> On Wednesday, 23 May 2018 10:31:15 -03 dgutson . wrote:
>> > I think that we could think about some requirements packed in somethin=
g
>> > like a memory_traits, where it would specify:
>> >   - pointer type (optionally volatile-qualified)
>> >   - alignment requirements
>> >   - memory synchronization needs / specifications (an enumerator)
>> >   - vectorization habilities
>>
>> Or, like I said, you can roll out your own memcpy or memset (which are
>> quite
>> trivial) if you have specific requirements.
>>
>
> I propose to leave "triviality" out of the discussion, since this can get
> combinatoric complex, and there is no metric of "triviality" either.
> There are many std functions that are arguably trivial as well, and
> despite that, they are in the STL because people use them.
> We can keep arguing about triviality, what is trivial and what isn't, and
> we will end up comparing somebody with Hitler as per Godwin's Law.
> Please forgive me, I sincerely respect you but this is not a discussion I
> would like to have.
>

(especially because you may end up also, as I mentioned at the beginning,
trying to control the optimizer preventing it to be too smart for "too
trivial loops").


>
>
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/1695197.Kxq4M8jdJr%40tjmaciei-mobl1.
>>
>
>
>
> --
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?
>



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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/CAFdMc-1S1HcBNWaOqB3VsDV1KMHkEO2Ne_Sa%3D5AZu4Num=
unfdw%40mail.gmail.com.

--00000000000093e581056ce1469b
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 Wed, May 23, 2018 at 12:33 PM, dgutson . <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:danielgutson@gmail.com" target=3D"_blank">danielgutson@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=
=3D"">On Wed, May 23, 2018 at 12:13 PM, Thiago Macieira <span dir=3D"ltr">&=
lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira=
..org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wedne=
sday, 23 May 2018 10:31:15 -03 dgutson . wrote:<br>
&gt; I think that we could think about some requirements packed in somethin=
g<br>
&gt; like a memory_traits, where it would specify:<br>
&gt;=C2=A0 =C2=A0- pointer type (optionally volatile-qualified)<br>
&gt;=C2=A0 =C2=A0- alignment requirements<br>
&gt;=C2=A0 =C2=A0- memory synchronization needs / specifications (an enumer=
ator)<br>
&gt;=C2=A0 =C2=A0- vectorization habilities<br>
<br>
</span>Or, like I said, you can roll out your own memcpy or memset (which a=
re quite <br>
trivial) if you have specific requirements.<br></blockquote><div><br></div>=
</span><div>I propose to leave &quot;triviality&quot; out of the discussion=
, since this can get combinatoric complex, and there is no metric of &quot;=
triviality&quot; either.</div><div>There are many std functions that are ar=
guably trivial as well, and despite that, they are in the STL because peopl=
e use them.</div><div>We can keep arguing about triviality, what is trivial=
 and what isn&#39;t, and we will end up comparing somebody with Hitler as p=
er Godwin&#39;s Law.</div><div>Please forgive me, I sincerely respect you b=
ut this is not a discussion I would like to have.</div></div></div></div></=
blockquote><div><br></div><div>(especially because you may end up also, as =
I mentioned at the beginning, trying to control the optimizer preventing it=
 to be too smart for &quot;too trivial loops&quot;).</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><span class=3D""><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<span><br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
</span><span>-- <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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/1695197.Kxq4M8jdJr%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<=
wbr>ocpp.org/d/msgid/std-proposals<wbr>/1695197.Kxq4M8jdJr%40tjmaciei<wbr>-=
mobl1</a>.<br>
</blockquote></span></div><br><br clear=3D"all"><span class=3D""><div><br><=
/div>-- <br><div class=3D"m_6545927412837870730gmail_signature" data-smartm=
ail=3D"gmail_signature">Who=E2=80=99s got the sweetest disposition?<br>One =
guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<=
br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but alway=
s right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck wit=
h all the bad luck? </div>
</span></div></div>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Who=E2=80=99s got t=
he sweetest disposition?<br>One guess, that=E2=80=99s who?<br>Who=E2=80=99d=
 never, ever start an argument?<br>Who never shows a bit of temperament?<br=
>Who&#39;s never wrong but always right?<br>Who&#39;d never dream of starti=
ng a fight?<br>Who get stuck with all the bad luck? </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/CAFdMc-1S1HcBNWaOqB3VsDV1KMHkEO2Ne_Sa=
%3D5AZu4Numunfdw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1S1HcBNW=
aOqB3VsDV1KMHkEO2Ne_Sa%3D5AZu4Numunfdw%40mail.gmail.com</a>.<br />

--00000000000093e581056ce1469b--

.

On Wednesday, 23 May 2018 12:33:02 -03 dgutson . wrote:
> > Or, like I said, you can roll out your own memcpy or memset (which are
> > quite
> > trivial) if you have specific requirements.
>
> I propose to leave "triviality" out of the discussion, since this can get
> combinatoric complex, and there is no metric of "triviality" either.

Sorry, but my point is that to write:

 for (size_t i = 0; i < n; ++i)
  dst[i] = src[i];

is quite trivial and does implement the most basic memcpy for byte-wise,
volatile data. This is what such a generic, volatile memcpy would do and I see
no use in providing it in the standard library since it can't differ from
that. There is no room for optimisation to be applied, unlike the normal
memcpy.

When you start adding requirements, this gets out of hand. The permutations
will explode:
 - memory fence or no?
 - how often should the memory fence be done? Is it per time, per address or
   per cumulative bytes copied?
 - which memory fence (load, store or full)?
 - which pointer controls the fence, source or destination?
 - can it read more than two bytes at a time? If so, must reads be aligned?
 - can it read four bytes at a time? If so, must 4-byte reads be aligned?
 - can it read eight... sixteen, thirty-two, sixty four?
 - can misaligned reads cross a cacheline? can they cross a page boundary?
 - repeat the read questions by replacing with write
 - can it read more than one element (whichever size) before writing it (i.e.,
   can it pipeline)?
 - should the stores use non-temporal cache hints? Which cache level?

My point is that the moment you need anything from that list above, you should
roll out your own code, for your own purposes. The operating system kernels
can have shared functions for this because they know which hardware they're
going to run on and thus what types of volatile memory behaviour they're going
to face. That is not the case for the C++ standard library.

However, if you want to provide this volatile memcpy as a library, you're
welcome to. You can limit your needs to modern architectures or just one (your
employer's), which should cut down the permutations from millions of
possibilities to just tens. The problem becomes manageable.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1802764.OhHZxBL3Cz%40tjmaciei-mobl1.

.

On Wednesday, 23 May 2018 13:05:07 -03 Thiago Macieira wrote:
> Sorry, but my point is that to write:
>
>         for (size_t i = 0; i < n; ++i)
>                 dst[i] = src[i];

By the way, this should be what

    std::copy_n(src, n, dst);

Should generate for volatile chars, but the compilation fails with both libc++
and libstdc++, as both try too aggressively to use memmove. Since I don't see
any requirement in the standard besides src and dst being valid InputIterator
and OutputIterator respectively, I believe that's a bug in both
implementations.

Microsoft's compiles. See https://godbolt.org/g/7yMhRy.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1660351.5grH1viArP%40tjmaciei-mobl1.

.

------=_Part_6048_49411746.1527462569626
Content-Type: multipart/alternative;
 boundary="----=_Part_6049_1616913416.1527462569626"

------=_Part_6049_1616913416.1527462569626
Content-Type: text/plain; charset="UTF-8"

On Friday, May 18, 2018 at 9:41:08 PM UTC+1, dgutson wrote:
>
> This might be interesting.
>
> In some systems, the implementation of memcpy() & friends cannot be used
> for memory-mapped devices.
> Usually, mapped memory is marked as volatile.
>
> I'm proposing to add volatile pointers overloads for the memcpy() function
> and friends, without specifying exactly what should be different at the
> standard-level, but allowing implementations to provide a particular
> behavior. I'm just proposing to add the declaration to the standard.
>
> Just there this weekend I, yet again, had to write a custom memcpy()
implementation because the built-in one can be elided by the compiler
during optimisation. I'd like to stop having to write memcpy() personally.

I think your idea has two variants:

   1. Cannot be optimised out memcpy/memset/memmove etc. I'd suggest
   secure_memset(), secure_memcpy(), secure_memmove() and so on rather than
   editions taking a volatile pointer.
   2. Said routines, but with additional std::memory_order parameter.

With respect to your ideas about i/o, you can't do that yet with the
current C++ memory model. There is no concept of making writes visible to
main memory, or to i/o devices, in some sequential order in the current C++
standard. The current C++ memory model only speaks of visibility to threads
of execution. It doesn't handle visibility to remote hardware, like network
cards, hard drives, graphics cards etc.

SG1 Concurrency are aware of this limitation, and may in the future decide
to address it. I would be sure that well written papers are welcome on that
topic.

I'd certainly like to see papers land before WG21 proposing secure_*()
functions, perhaps with overloads with std::memory_order parameter. The
latter should be sent to SG1 I would suspect, the former could just go to
LEWG.

Niall

--
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/420b274b-fc4b-413e-8ce9-b78131c782f7%40isocpp.org.

------=_Part_6049_1616913416.1527462569626
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 18, 2018 at 9:41:08 PM UTC+1, dgutson wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">This might b=
e interesting.<div><br></div><div>In some systems, the implementation of me=
mcpy() &amp; friends cannot be used for memory-mapped devices.</div><div>Us=
ually, mapped memory is marked as volatile.</div><div><br></div><div>I&#39;=
m proposing to add volatile pointers overloads for the memcpy() function an=
d friends, without specifying exactly what should be different at the stand=
ard-level, but allowing implementations to provide a particular behavior. I=
&#39;m just proposing to add the declaration to the standard.</div><div><br=
></div></div></blockquote><div>Just there this weekend I, yet again, had to=
 write a custom memcpy() implementation because the built-in one can be eli=
ded by the compiler during optimisation. I&#39;d like to stop having to wri=
te memcpy() personally.</div><div><br></div><div>I think your idea has two =
variants:</div><div><ol><li>Cannot be optimised out memcpy/memset/memmove e=
tc. I&#39;d suggest secure_memset(), secure_memcpy(), secure_memmove() and =
so on rather than editions taking a volatile pointer.</li><li>Said routines=
, but with additional std::memory_order parameter.</li></ol><div>With respe=
ct to your ideas about i/o, you can&#39;t do that yet with the current C++ =
memory model. There is no concept of making writes visible to main memory, =
or to i/o devices, in some sequential order in the current C++ standard. Th=
e current C++ memory model only speaks of visibility to threads of executio=
n. It doesn&#39;t handle visibility to remote hardware, like network cards,=
 hard drives, graphics cards etc.</div></div><div><br></div><div>SG1 Concur=
rency are aware of this limitation, and may in the future decide to address=
 it. I would be sure that well written papers are welcome on that topic.</d=
iv><div><br></div><div>I&#39;d certainly like to see papers land before WG2=
1 proposing secure_*() functions, perhaps with overloads with std::memory_o=
rder parameter. The latter should be sent to SG1 I would suspect, the forme=
r could just go to LEWG.</div><div><br></div><div>Niall</div><div><br></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/420b274b-fc4b-413e-8ce9-b78131c782f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/420b274b-fc4b-413e-8ce9-b78131c782f7=
%40isocpp.org</a>.<br />

------=_Part_6049_1616913416.1527462569626--

------=_Part_6048_49411746.1527462569626--

.

--000000000000e41f37056d38d5b0
Content-Type: text/plain; charset="UTF-8"

On Monday, May 28, 2018, Niall Douglas <nialldouglas14@gmail.com> wrote:

> On Friday, May 18, 2018 at 9:41:08 PM UTC+1, dgutson wrote:
>>
>> This might be interesting.
>>
>> In some systems, the implementation of memcpy() & friends cannot be used
>> for memory-mapped devices.
>> Usually, mapped memory is marked as volatile.
>>
>> I'm proposing to add volatile pointers overloads for the memcpy()
>> function and friends, without specifying exactly what should be different
>> at the standard-level, but allowing implementations to provide a particular
>> behavior. I'm just proposing to add the declaration to the standard.
>>
>> Just there this weekend I, yet again, had to write a custom memcpy()
> implementation because the built-in one can be elided by the compiler
> during optimisation. I'd like to stop having to write memcpy() personally.
>
> I think your idea has two variants:
>
>    1. Cannot be optimised out memcpy/memset/memmove etc. I'd suggest
>    secure_memset(), secure_memcpy(), secure_memmove() and so on rather than
>    editions taking a volatile pointer.
>    2. Said routines, but with additional std::memory_order parameter
>
>
Or just stop compilers from doing daft things

--
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/CAFQaeCD83_FBX4cAE%2B9AAEHai4ciCeOaorHY1K94k_Yb0e9wnA%40mail.gmail.com.

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

<br><br>On Monday, May 28, 2018, Niall Douglas &lt;<a href=3D"mailto:nialld=
ouglas14@gmail.com">nialldouglas14@gmail.com</a>&gt; wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">On Friday, May 18, 2018 at 9:41:08 PM U=
TC+1, dgutson wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">This might be interesting.<div><br></div><div>In some systems, the implem=
entation of memcpy() &amp; friends cannot be used for memory-mapped devices=
..</div><div>Usually, mapped memory is marked as volatile.</div><div><br></d=
iv><div>I&#39;m proposing to add volatile pointers overloads for the memcpy=
() function and friends, without specifying exactly what should be differen=
t at the standard-level, but allowing implementations to provide a particul=
ar behavior. I&#39;m just proposing to add the declaration to the standard.=
</div><div><br></div></div></blockquote><div>Just there this weekend I, yet=
 again, had to write a custom memcpy() implementation because the built-in =
one can be elided by the compiler during optimisation. I&#39;d like to stop=
 having to write memcpy() personally.</div><div><br></div><div>I think your=
 idea has two variants:</div><div><ol><li>Cannot be optimised out memcpy/me=
mset/memmove etc. I&#39;d suggest secure_memset(), secure_memcpy(), secure_=
memmove() and so on rather than editions taking a volatile pointer.</li><li=
>Said routines, but with additional std::memory_order parameter</li></ol></=
div></div></blockquote><div><br></div><div>Or just stop compilers from doin=
g daft things=C2=A0</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/CAFQaeCD83_FBX4cAE%2B9AAEHai4ciCeOaor=
HY1K94k_Yb0e9wnA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCD83_FBX4=
cAE%2B9AAEHai4ciCeOaorHY1K94k_Yb0e9wnA%40mail.gmail.com</a>.<br />

--000000000000e41f37056d38d5b0--

.

--000000000000cb4a18056d38e68f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El dom., 27 de mayo de 2018 21:02, j c <james.a.cooper@gmail.com> escribi=
=C3=B3:

>
>
> On Monday, May 28, 2018, Niall Douglas <nialldouglas14@gmail.com> wrote:
>
>> On Friday, May 18, 2018 at 9:41:08 PM UTC+1, dgutson wrote:
>>>
>>> This might be interesting.
>>>
>>> In some systems, the implementation of memcpy() & friends cannot be use=
d
>>> for memory-mapped devices.
>>> Usually, mapped memory is marked as volatile.
>>>
>>> I'm proposing to add volatile pointers overloads for the memcpy()
>>> function and friends, without specifying exactly what should be differe=
nt
>>> at the standard-level, but allowing implementations to provide a partic=
ular
>>> behavior. I'm just proposing to add the declaration to the standard.
>>>
>>> Just there this weekend I, yet again, had to write a custom memcpy()
>> implementation because the built-in one can be elided by the compiler
>> during optimisation. I'd like to stop having to write memcpy() personall=
y.
>>
>> I think your idea has two variants:
>>
>>    1. Cannot be optimised out memcpy/memset/memmove etc. I'd suggest
>>    secure_memset(), secure_memcpy(), secure_memmove() and so on rather t=
han
>>    editions taking a volatile pointer.
>>    2. Said routines, but with additional std::memory_order parameter
>>
>>
> Or just stop compilers from doing daft things
>

FWIW, from my previous team:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D69976

--=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
> 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/CAFQaeCD83_F=
BX4cAE%2B9AAEHai4ciCeOaorHY1K94k_Yb0e9wnA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCD83_=
FBX4cAE%2B9AAEHai4ciCeOaorHY1K94k_Yb0e9wnA%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=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/CAFdMc-1x-jV8fwXj7%3DS5-XjA1yMTNVBJYQiwpNVO52-Sk=
4X6CQ%40mail.gmail.com.

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
El dom., 27 de mayo de 2018 21:02, j c &lt;<a href=3D"mailto:james.a.cooper=
@gmail.com">james.a.cooper@gmail.com</a>&gt; escribi=C3=B3:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><br><br>On Monday, May 28, 2018, Niall Douglas &lt=
;<a href=3D"mailto:nialldouglas14@gmail.com" target=3D"_blank" rel=3D"noref=
errer">nialldouglas14@gmail.com</a>&gt; wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Friday, May 18, 2018 at 9:41:08 PM UTC+1, dgutson=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This might =
be interesting.<div><br></div><div>In some systems, the implementation of m=
emcpy() &amp; friends cannot be used for memory-mapped devices.</div><div>U=
sually, mapped memory is marked as volatile.</div><div><br></div><div>I&#39=
;m proposing to add volatile pointers overloads for the memcpy() function a=
nd friends, without specifying exactly what should be different at the stan=
dard-level, but allowing implementations to provide a particular behavior. =
I&#39;m just proposing to add the declaration to the standard.</div><div><b=
r></div></div></blockquote><div>Just there this weekend I, yet again, had t=
o write a custom memcpy() implementation because the built-in one can be el=
ided by the compiler during optimisation. I&#39;d like to stop having to wr=
ite memcpy() personally.</div><div><br></div><div>I think your idea has two=
 variants:</div><div><ol><li>Cannot be optimised out memcpy/memset/memmove =
etc. I&#39;d suggest secure_memset(), secure_memcpy(), secure_memmove() and=
 so on rather than editions taking a volatile pointer.</li><li>Said routine=
s, but with additional std::memory_order parameter</li></ol></div></div></b=
lockquote><div><br></div><div>Or just stop compilers from doing daft things=
=C2=A0</div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">FWIW, from my previous team:=C2=A0<a href=3D"https://gcc.gnu.org/=
bugzilla/show_bug.cgi?id=3D69976">https://gcc.gnu.org/bugzilla/show_bug.cgi=
?id=3D69976</a></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">

<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" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/CAFQaeCD83_FBX4cAE%2B9AAEHai4ciCeOaor=
HY1K94k_Yb0e9wnA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAFQaeCD83_FBX4cAE%2B9AAEHai4ciCeOaorHY1K94k_Yb0e=
9wnA%40mail.gmail.com</a>.<br>
</blockquote></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/CAFdMc-1x-jV8fwXj7%3DS5-XjA1yMTNVBJYQ=
iwpNVO52-Sk4X6CQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1x-jV8fw=
Xj7%3DS5-XjA1yMTNVBJYQiwpNVO52-Sk4X6CQ%40mail.gmail.com</a>.<br />

--000000000000cb4a18056d38e68f--

.

On 05/28/2018 01:09 AM, Niall Douglas wrote:
> Just there this weekend I, yet again, had to write a custom memcpy()
> implementation because the built-in one can be elided by the compiler
> during optimisation. I'd like to stop having to write memcpy()
> personally.
>
> I think your idea has two variants:
>
> 1. Cannot be optimised out memcpy/memset/memmove etc. I'd suggest
> secure_memset(), secure_memcpy(), secure_memmove() and so on rather
> than editions taking a volatile pointer.

ISO C11 has memset_s in K.3.7.4.1.

Jens

--
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/5B0BFB66.7080501%40gmx.net.

.

On 05/28/18 15:51, Jens Maurer wrote:
> On 05/28/2018 01:09 AM, Niall Douglas wrote:
>> Just there this weekend I, yet again, had to write a custom memcpy()
>> implementation because the built-in one can be elided by the compiler
>> during optimisation. I'd like to stop having to write memcpy()
>> personally.
>>
>> I think your idea has two variants:
>>
>> 1. Cannot be optimised out memcpy/memset/memmove etc. I'd suggest
>> secure_memset(), secure_memcpy(), secure_memmove() and so on rather
>> than editions taking a volatile pointer.
>
> ISO C11 has memset_s in K.3.7.4.1.

Annex K is basically dead and is considered for for removal, as I heard.

There are a few non-portable replacements, though.

http://netbsd.gw.com/cgi-bin/man-cgi?explicit_memset+3+NetBSD-current
https://manpages.debian.org/testing/manpages-dev/bzero.3.en.html

Having a portable equivalent of explicit_memset & co. in the standard
(but not Annex K) would be really useful.

--
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/09b7df78-9694-896f-dc0c-e3e5f5ac3c42%40gmail.com.

.