Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 9 Sep 2024 12:22:19 +0300
Organization: A noiseless patient Spider
Lines: 123
Message-ID: <20240909122219.00007f81@yahoo.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
	<memo.20240830164247.19028y@jgd.cix.co.uk>
	<vasruo$id3b$1@dont-email.me>
	<2024Aug30.195831@mips.complang.tuwien.ac.at>
	<vat5ap$jthk$2@dont-email.me>
	<vaunhb$vckc$1@dont-email.me>
	<vautmu$vr5r$1@dont-email.me>
	<2024Aug31.170347@mips.complang.tuwien.ac.at>
	<vavpnh$13tj0$2@dont-email.me>
	<vb2hir$1ju7q$1@dont-email.me>
	<8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com>
	<vb3k0m$1rth7$1@dont-email.me>
	<17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org>
	<86v7zep35n.fsf@linuxsc.com>
	<20240902180903.000035ee@yahoo.com>
	<vb7ank$3d0c5$1@dont-email.me>
	<20240903190928.00002f92@yahoo.com>
	<vb7idh$3e2af$1@dont-email.me>
	<86seufo11j.fsf@linuxsc.com>
	<vba6qa$3u4jc$1@dont-email.me>
	<1246395e530759ac79805e45b3830d8f@www.novabbs.org>
	<8634m9lga1.fsf@linuxsc.com>
	<vbmb3h$2bfqh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Sep 2024 11:21:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="45fff2496b15112b5e4e03cadfa28742";
	logging-data="2041887"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/OK+kp6sjt36GOTh4sGM/zZBNrObA1L1I="
Cancel-Lock: sha1:rX71s5cQCIcFe/LyHsdMvz3Y1/Q=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 5795

On Mon, 9 Sep 2024 10:20:00 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> Tim Rentsch wrote:
> > mitchalsup@aol.com (MitchAlsup1) writes:
> >   
> >> On Wed, 4 Sep 2024 17:53:13 +0000, David Brown wrote:
> >>  
> >>> On 04/09/2024 18:07, Tim Rentsch wrote:
> >>>  
> >>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
> >>>>  
> >>>>> Michael S wrote:
> >>>>>  
> >>>>>> On Tue, 3 Sep 2024 17:41:40 +0200
> >>>>>> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> >>>>>>  
> >>>>>>> Michael S wrote:
> >>>>>>>  
> >>>>>>>> 3 years ago Terje Mathisen wrote that many years ago he read
> >>>>>>>> that behaviour of memcpy() with overlappped src/dst was
> >>>>>>>> defined.
> >>>>>>>> https://groups.google.com/g/comp.arch/c/rSk8c7Urd_Y/m/ZWEG5V1KAQAJ
> >>>>>>>> Mitch Alsup answered "That was true in 1983".  So, two
> >>>>>>>> people of different age living in different parts of the
> >>>>>>>> world are telling the same story.  May be, there exist old
> >>>>>>>> popular book that said that it was defined?  
> >>>>>>>
> >>>>>>> It probably wasn't written in the official C standard, which I
> >>>>>>> couldn't have afforded to buy/read, but in a compiler runtime
> >>>>>>> doc?
> >>>>>>>
> >>>>>>> Specifying that it would always copy from beginning to end of
> >>>>>>> the source buffer, in increasing address order meant that it
> >>>>>>> was guaranteed safe when used to compact buffers.  
> >>>>>>
> >>>>>> What is "compact buffers" ?  
> >>>>>
> >>>>> Assume a buffer consisting of records of some type, some of
> >>>>> them marked as deleted.  Iterating over them while removing
> >>>>> the gaps means that you are always copying to a destination
> >>>>> lower in memory, right?  
> >>>>
> >>>> If all the records are in one large array, there is a simple
> >>>> test to see if memcpy() must work or whether some alternative
> >>>> should be used instead.  
> >>>
> >>> Such tests are usually built into implementations of memmove(),
> >>> which will chose to run forwards or backwards as needed.  So you
> >>> might as well just call memmove() any time you are not sure
> >>> memcpy() is safe and appropriate.  
> > 
> > The ever-shallow David Brown first misses the point, then makes a
> > slightly incorrect statement, and finally makes a recommendation
> > that surely is familiar to every reader in the newsgroup.
> >   
> >> Memmove() is always appropriate unless you are doing something
> >> nefarious.
> >>
> >> So:
> >> # define memcpy memomve  
> > 
> > Incidentally, if one wants to do this, it's advisable to write
> > 
> >    #undef  memcpy
> > 
> > before the #define of memcpy.  
> 
> What really worries me is that I've been told (and shown in godbolt) 
> that memcpy() can be magic, i.e the ocmpiler is allowed to make it
> NOP when I use it to move data between an integer and float variable:
> 
> float invsqrt(float x)
> {
>    ...
>    int32_t ix = *(int32_t *) &x;
> 
> is deprecated, instead do something like this:
> 
>    int32_t ix;
>    memcpy(&ix, &x, sizeof(ix));
> 
> and the compiler will see that x and ix can share the same register.
> 
> I don't suppose memmove() can be dependent upon to do the same?
> 
> Terje
> 

In simple situations like shown above, memmove is as dependable as
memcpy.

I don't know if it is always true in more complex cases, where absence
of aliasing is less obvious to compiler. However, I'd expect that as
long as a copied item fits in register, the magic will work equally
with both memcpy and memmove.

It depends on compiler, too.
MSVC from VS2019 produces the same code for both variants d_to_u below.
But MSVC from VS2017 does not.

#include <stdint.h>
#include <string.h>

void d_to_u_cpy(uint64_t* u, const double* d) {
  memcpy(u, d, sizeof(*u));
}

#define memcpy memmove

void d_to_u_move(uint64_t* u, const double* d) {
  memcpy(u, d, sizeof(*u));
}