Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 4 Sep 2024 15:06:46 -0500
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <vbaekq$3uvnb$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 22:06:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8de94f8feec99f95a188a9107769a9f3";
	logging-data="4161259"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19T5ook924hzAv/i956DTZZBRIpa8Yi8Fk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ip/8pLCRluZkJw/rz5M//H+y+zM=
In-Reply-To: <1246395e530759ac79805e45b3830d8f@www.novabbs.org>
Content-Language: en-US
Bytes: 5555

On 9/4/2024 1:13 PM, MitchAlsup1 wrote:
> 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.
> 
> Memmove() is always appropriate unless you are doing something
> nefarious.
> So:
> # define memcpy memomve
> and move forward with life--for the 2 extra cycles memmove costs it
> saves everyone long term grief.
> 

Pretty reasonable.
If you want to move intact data around within overlapping buffers or 
arrays, then yes, memmove makes sense.


> When you need the nefarious activities of memcpy write it as a
> for loop by yourself and comment the nafariousness of the use.

I had added _memlzcpy() to my C library implementation:
It specifically mimics the behavior of a loop copying bytes 
one-at-a-time, as typically needed for LZ77 implementations, but aiming 
to be moderately efficient about it (with the same general interface as 
memcpy and memmove).

You don't want an actual "byte at a time" copy loop, because this is 
painfully slow, so it turns into a bunch of hair to mimic the behavior 
while copying typically 16 or 32 byte blocks.


Then, also, _memlzcpyf(), which is similar, but may access and stomp 
16-32 bytes past the end of the source and destination (in these sorts 
of memory copies, dealing accurately with the last "mod N" bytes can be 
fairly expensive).

It can also be used for multi-byte memset.
   _memlzcpy(dst+4, dst, 16380);
Will fill the destination with 16K worth of copies of the first 4 bytes.


But, the downside is that these have a higher constant-time cost (vs 
memcpy and memmove), and are generally also slower for bulk copy (vs 
memmove or memcpy). Some of this is partly because getting an accurate 
self-overlapping copy set up is more involved than a plain memory copy.



Generally, memmove only really needs to compare the addresses:
   dst<src:
     Copy in forward direction;
   dst>src:
     Copy in backwards direction;
   dst==src:
     Do nothing.