Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 9 Sep 2024 10:20:00 +0200
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <vbmb3h$2bfqh$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 09 Sep 2024 10:20:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0116348fdc9cc4f161bd0f09196863ce";
	logging-data="2473809"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/fRTyPxxgqPC24scJtC4F8hWRSzlZAKN1OtSf7PlrNGg=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:4koXSaAq2NOoEwRbSpbdTFdrfpo=
In-Reply-To: <8634m9lga1.fsf@linuxsc.com>
Bytes: 4945

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

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"